Tag Archives: jack

What Happens When You Forget to Write A Blog Post?

Posted on by

“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), 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.

Keeping it All in Your Head

Posted on by

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), 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.

 

Level Design

Posted on by

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.

Inspirations

Posted on by

Almost everyone involved in indie game development these days gets into it for the same reason – we played games, we liked those games, and they inspired us to make our own games. We want to capture whatever it was that made us love the games we played when we were younger. Whether it was the storyline, the art style, or the gameplay itself, these games made us who we are, and they influence every decision we make in our own games.

A few weeks ago, I was discussing game development with a friend when they asked me “what are your favorite video games?” After I rattled off a few, they asked another question – “Why?” This was followed by a really interesting conversation, because the games I chose were so different, and yet they all influenced the way that I design and make games now.

So I’m going to share that list with you now. I’m going to tell you my favorite video games and how they have affected my own game development, and I hope you’ll think about your own answer to the question as well; what games make you want to make games?

 

Monument Valley

Image result for monument valley game

When screenshots of your game are good enough to be your part of your marketing material, you know you have a beautiful game

I’m gonna start here, because I mentioned it last week, and because everyone is expecting it. If you’ve played Where Shadows Slumber, then it probably reminds you of Monument Valley. This isn’t exactly intentional, but I would be lying if I said that we weren’t inspired by Monument Valley in a lot of our design decisions.

There are a few things that Monument Valley did that were very important. First and foremost, it’s beautiful. I’m not one who really focuses on how the games I play look, but Monument Valley manages to be beautiful beyond the point of ‘good graphics’ and actually into the realm of ‘art’. This aesthetic quality is something that isn’t necessary for a game, but if you go for it, it definitely wins some points.

Secondly, Monument Valley showed that you can have a game with an incredibly simple concept, yet still have intricate, mind-bending puzzles. Additionally, it does so on a form-factor (mobile) that doesn’t lend itself nicely to this type of intricate, high-quality game, and still managed to do well, despite the industry’s focus on the ‘freemium’ monetization model. Monument Valley showed, most of all, that if you really put a lot of work into making a truly incredible game, you can be rewarded for it.

 

StarCraft: Brood War

Image result for starcraft brood war

Graphics aside, still one of the best games out there

Ah, StarCraft. This is really where it all began for me. This was one of the first games I really got into, and it became a very important part of my childhood. If I had to pick one game on this list as my all-time favorite, it would have to be StarCraft.

When I was talking about my favorite games and StarCraft came up, I tried to think of why it was my favorite game, from a game design perspective. StarCraft is a very complex and strategic game. The skill cap is incredibly high, and there’s always room for mind games and counter-play. I played a lot of competitive games of StarCraft, and I spent hours perfecting my worker split (for those of you who don’t know what that means, just be glad you didn’t have to do it). The depth this game has is fantastic – but are any of those really the reason I loved StarCraft so much?

No – the reason I loved StarCraft so much was the way it created memories of playing with friends. It wasn’t the game itself that made it fun, it was the people I played it with. When I think of StarCraft, I think of the 5-player game where one friend had nothing but a single pylon and about 40 Corsairs – every time someone else won a battle, those corsairs would arrive to finish off his fleet. I think of the time I won a game by building nothing but Ghosts and Valkyries, for some reason. I think of the EMP-Nuke rushes, the epic micro battles, and the mind games. Most of all, I think of laughing with my friends as it all went down, and even occasionally loading up a few replays and just watching them.

Children’s special on the meaning of friendship aside, these stories and interactions are the reason I love StarCraft. Unfortunately, that doesn’t really inform any of our game design decisions – you can’t build any of that stuff into a game. What you can do is make a game that has the potential for these stories. Make it so that your players can do crazy, funny, awesome things. Your game may be strategic, intense, and mind-blowing, but, above all else, you need to make sure that it’s fun.

 

Cave Story

Image result for cave story

I can’t think of a quote for this picture

Cave Story is a testament to what indie games can accomplish. Cave Story was created, music, art, gameplay, and all, start to finish, by one guy in his spare time. And, aside from being an inspiring story, it’s also an incredibly great game!

In my mind, the reason that Cave Story is so good is that it doesn’t make any concessions. Every part of the game is great. The storyline? Funky, but really cool. The gameplay? Skill-testing and engaging. The music? Amazing! For almost any facet of a game that you might ask about, the answer for Cave Story would be “yeah, it has that, and it’s awesome!” It just feels like an absolutely complete game. Comparing a game like Cave Story to a lot of the pretty good, mostly-finished games you see really drives home the importance of actually finishing your game. Rather than saying “yeah, the controls are a little off, but it’s not a big deal”, get in there and fix them!

The other big reason to talk about Cave Story on a game development blog is because of its development. Cave Story has become a sort of cult classic, in a good way. It’s so incredibly inspiring that one guy can make such a great game in his spare time.

 

Rocket League

RL

Calculated.

Rocket League, also known as Hot-Wheels soccer, is the game I’ve been playing the most recently. As such, I have a pretty good feeling for why I like it so much. There are really two reasons.

 

(1) The controls in Rocket League are phenomenal. Imagine you’re playing some other game, and you miss an objective (whether it be a goal or a kill or whatever). Inside your head you’ll end up saying “I would have had it if the controls were better”, or “I was trying to move to the left, but my guy didn’t go where I wanted”, or something like that. You can always blame the game, rather than yourself.

In Rocket League, you don’t have that luxury. Once you figure out the controls, it’s all on you – when you tell your car to do something, your car does exactly that. This can lead to a little frustration, but it also leads to some absolutely incredible plays from the pros, and it means that every time you do something right, you feel that much better about it. There’s no better feeling than flying through the air, using your boost and turning you car in exactly the right way to score a crazy goal, and knowing that it was all you. That feeling wouldn’t be possible without the most finely-tuned controls.

 

(2) The other great thing about Rocket League is what I’m going to call it’s ‘skill curve’. This is different from a ‘learning curve’ – a learning curve implies that the game gets harder as you go, so you have to learn in order to beat it. The ‘skill curve’ is the inverse of this. You’re never ‘not good enough’ for a game; rather, as you play, you get better. This is true of most games, but it feels the most rewarding in Rocket League.

When you first start to play, you have a hard time hitting the ball. With enough practice, you start to hit it pretty consistently – that advance in skill is noticeable, and it feels great. Just as you’re getting good at that, you realize you’re not rotating properly. When you start to master that, you begin doing aerials. You’re always getting better, and you always feel like you’re getting better – your skill level never plateaus, you just keep getting good at the game.

 

Rocket League isn’t what I would call a deep game. There’s no storyline, no (or very few) different levels, nothing really new about the game. Psyonix does release different game modes and new maps from time to time, but the core gameplay remains mostly unchanged. And yet, despite this, it’s the game I keep returning to. It never really gets stale, thanks to its controls and skill curve, which is incredible for such a straightforward game. Rocket League shows that you can give any game a lot of replay value just by making it well.

 

Portal

Image result for portal

In search of cake

Portal is just an incredibly solid example of a well-put-together game. At the time, it seemed to be a sort of ‘add-on’ game, a little nugget that Valve added into The Orange Box. While the other titles in The Orange Box (Team Fortress 2 and Half Life 2) were really awesome, it was Portal that stood out to me, and to most people that I talk to.

Why? Well, Portal wasn’t just another game. The thing that excites me most about any game is when it explores new design space, and that’s exactly what Portal did. There were no guns to shoot (well, no real guns), no enemies to destroy, no princesses to rescue. You’re simply introduced to the world and the theory of portals, and you have to make your way through it. Your only weapon is the portal gun, and your only enemies are the levels themselves. It’s a very simple distillation of the essence of a puzzle. This is something that I aim for when designing my own puzzles – if you still have design space to explore, there’s no need to complicate your levels.

Portal really provides us with a master class on not overstaying your welcome. Really, it was the perfect length for what it was. You learn the mechanic, you get to used it, and you advance through puzzles with it. By the time you reach the end, you’ve explored most of the design space, but haven’t gotten to a point where it’s become timesome or tedious.

Plus, Portal does a great job of indicating its short, jolly mood through the use of its witty writing. This combination of very pure puzzles and inviting storyline is a design marvel, as it makes it very easy to draw a player into your game. The biggest takeaway from Portal, for me, is that more game doesn’t necessarily make for a better game. Content is king, and having more gameplay is usually a good thing, but it is possible to focus too much on length, rather than good design or implementation, and end up ‘overstaying your welcome’.

 

What I’m Most Looking Forward To

In addition to games from the past, let’s take a look at a game from the future! The future game I’m most looking forward to (other than Where Shadows Slumber) is a game I saw at PAX East this year. I only got to play the demo for a few minutes, but I’ve been really excited for it ever since. And the winner is… The Gardens Between!

Image result for the gardens between

Check out the haunting cell-shaded indie goodness!

After checking this game out, I’m sure you’re not surprised that I chose it. After all, it’s an indie game with a cell-shaded art style, a slight metaphysical twist, and gameplay based at least in part on lanterns! How could I not love it?

Parallels with Where Shadows Slumber aside, this game looks awesome. The controls are very simple and intuitive, and yet the puzzles show a depth that promises very interesting and challenging interactions. The game looks relaxing, sleek, and challenging, which, to me, makes for an awesome upcoming game. Props to The Voxel Agents on what looks to be a great title!

 

That’s Not All…

This list is by no means exhaustive. In fact, in an effort to pick my favorite games, I’ve left out some games that perhaps played an even bigger role in turning me into a game developer. There’s the first game that really got me into gaming (Runescape), the game that first got me interested in making games (Block Dude), and the game that I probably spent the most time playing (World of Warcraft), but, as important as these games were to me, I don’t really consider any of them to be in my top 5 favorite games.

Despite their differences, each of these games (and any game I’ve ever played, really) has had an effect on the decisions I make when working on Where Shadows Slumber or anything else. These games are all very important to me personally, and I hope I’ve done a decent job of explaining what each of them brings to the table, design-wise. Hopefully you’ll be inspired to examine your favorite games, and the design patterns involved in them!

 

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

If you have questions about my favorite games, or just want to share your own, feel free to contact us on social media! 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.