Show Prep!

For those of you who haven’t heard, Frank and I will be trekking down to Austin, Texas tomorrow to represent Where Shadows Slumber in South By Southwest’s Gamer’s Voice Awards! It’s a real honor to have been invited, and we’re super psyched to participate in one of the biggest media conferences in the world.

Of course, attending a show like this isn’t a walk in the park. There’s a lot of stuff we have to do to get ready for it, and that’s not even including the toll the show itself takes on us.

Since we’re going to SXSW tomorrow, last week was prep week. Let’s take a quick look at what that prep involves.

 

4-4-Fountain

 

Pre-Show: Game Prep

The whole point of these conventions is to show off Where Shadows Slumber, so one of the most important parts of preparing for the show is making sure we have a version of the game ready. One of the biggest surprises I’ve found is how much time and effort this takes. Since we’re actively working on making a game, you would think that we would be able to build and deploy it in a matter of minutes. However, this model of game development isn’t quite correct – having a game that’s 90% complete doesn’t mean we have a complete game with 90% as much content. Rather, it means that we have a game where most of its parts are 100% complete, and some of them haven’t even been started; we might even have a bunch of complete pieces that aren’t hooked up together.

Unfortunately, this means that show prep is quite time-consuming. It mostly comes down to the minutiae – we update the game’s build settings from “easy to develop” mode to “ready for production” mode. We have to change some configuration in order to bring only the levels we want. Small bugs or visual glitches are things we often ignore for the time being and revisit after level design and implementation is complete, but they have to be fixed for a show (even if they’re going to be changed again later). If we weren’t planning on implementing something (like menus), we may have to throw together a crude version just for the current show.

These annoying little time-wasters are one of the reasons we made the demo version of the game – no matter where we are in development, we can always simply bring the demo to a show, and know that it will work. However, as development has stretched out, we find that we don’t reap very much reward from showing the demo; people have already seen it, we’ve already heard all of the same feedback on it, and it doesn’t do a great job of showing how far Where Shadows Slumber has come. Especially for a big show like SXSW, we like to have a build of the game that has some recent work and shows off how awesome it can be, even if it does require jumping through a few more hoops.

After all of that, the only thing left is to actually build the game. This process is pretty easy for Android, and a little more complex for iOS, but it’s not too bad in either case. Then we actually test out the build on our devices, to ensure that users will get the best experience they can out of Where Shadows Slumber. If there are any bugs, then we have to go in, fix them, and build again. This is a much more time-consuming debugging process than usual, but, again, it’s usually worth it to get a chance to show off the most recent developments of the game.

 

20180313_130606

Buttons from Herb Ferman, dropcards from Moo, and Alba & Noah’s Phoz cards!

 

Pre-Show: Physical Prep

The most important part of showing off the game is the game itself, but that doesn’t mean there aren’t other things that need to be done. First and foremost, we need travel and lodging – a show isn’t much good if we’re not there for it! This is one of the reasons we go to a lot of shows in the northeast, but not too many elsewhere; we can often drive to Boston or Washington D.C., and sometimes we even know someone who lives nearby (and is willing to put up with us).

Another important factor in going to shows is actually being allowed to show Where Shadows Slumber at the show. This involves a lot of emailing back and forth with the convention runners, whether it’s them inviting us and us accepting, or us begging them to let us come.

Once we know where we’re staying and how we’re getting there, we have to figure out what else we’re going to bring. Most of this comes from a pretty stock list – we need devices to showcase on, computers to play videos, our banner, a tablecloth, foam floor padding, etc. On top of that, we like to bring business cards (above), and sometimes Where Shadows Slumber buttons. These can take some time to design, because we like to use very recent content from the game. After that, the only thing left is to coordinate between us when and where we’re going to meet, and it’s off to the show!

I should mention that most of the non-game prep that goes into these shows is done by Frank. He’s the one in charge of Game Revenant’s bankroll, so he ends doing anything that requires actually purchasing something. Which is pretty awesome, because I’m far too scatterbrained to handle organizing any of that stuff.

 

gaming_ma

The Show Itself!

I know this post is about the show prep, but I would be remiss if I failed to mention the show itself! The preparation is a lot of tedious stuff that makes us feel like we’re wasting time, but actually going to the show is the part that really exhausts us. We’ve spent a lot of time and effort making a great game to show people (both in terms of specific show prep and in general), so we end up spending 2-4 days showing it to literally every person we meet. And at a large convention, that usually ends up being several hundred people. We’re on our feet, talking, conversing, explaining, and schmoozing for pretty much the entire convention – it really takes it out of you!

All in all, show prep is a necessary evil. When you’re already spending most of your free time working on something, it’s really galling to have to spend even more time on more tedious parts of that project. But, once we get to the show, it quickly becomes clear that it’s all worth it. Frank and I are pretty used to Where Shadows Slumber at this point, but seeing the look on someone’s face when they realize what’s going on for the first time is a really great feeling. And knowing that we put in the work to bring the best possible version of the game to a show really helps us understand how people are going to react to the final game itself.

I should probably wrap this post up. Honestly, it’s shorter than most of my other posts, and probably not quite as good, but I don’t really have any time to make it better – I have to fix a bunch of bugs before we leave for South by Southwest tomorrow!

 

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

I hope you enjoyed a look at our pre-show process – if you have any questions about our con-going habits or anything else, we would love to hear from you (although we probably won’t get back to you until after SXSW). You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, join the Game Revenant Discord, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com. And if you’re in Austin this weekend, make sure you come by our booth!

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

Menus

I’ve been talking a lot about less technical stuff recently. Let’s mix it up – today, I’m gonna talk all about the design and implementation of an important part of our game. If you couldn’t guess from the title, today we’re gonna talk about menus!

Design

Menus are a pretty important part of your game. Most people make a game and then just “slap” a menu down on top of it. Since the menu is the first thing users will see, it can be pretty make-or-break, so it seems like poor form to spend the least amount of time on it! That’s why it’s so important to actually put some thought into your menu design.

Early on, Frank and I decided that we wanted to have as little text in Where Shadows Slumber as possible. There were a number of reasons for this, the most obvious being:

  • We have to do less work to translate the game into other languages
  • It adds to the “mysterious” vibe we’ve been going for
  • The user isn’t burdened with a bunch of text they have to read
  • The text-based menus were possibly the worst part of SkyRunner (our previous game)

To go along with this choice, we also aimed to make the menus as transient as possible – rather than opening to a menu, where the player must choose to start playing, the game itself would just start playing immediately. That’s what the user is here for, after all! This “game-focused” menu model is an attempt to reduce the user’s barrier to entry, making it as easy as possible to actually start playing the game.

So what does that look like? Our menu design breaks down into four small parts:

  1. The first thing the user will see is the splash screen. This is just a quick little screen that shows the Where Shadows Slumber logo. It’s not really a menu, since it doesn’t do anything, but it’s worth mentioning (and it’s important for implementation purposes).
  2. Before starting a level, the user is met with a level title card. This tells the user what level they’re on, which provides important context, as it’s the only menu interaction they’ll have before they get to the game itself. After tapping through this menu, the user is dropped right into the game.
  3. During the game, the user can press the pause button, which will bring them to the pause menu. This is where most of the interaction is – you can restart the level, mess with the settings, etc. In order to move from “menu-focused” to “game-focused”, we’ve moved everything you would see in a “main menu” into the pause menu.
  4. The only exception to the “game-focused” menu design is our level select menu. Coming here will actually take you out of the game – but for good reason. This menu is by far the most complex, as the user can choose from any of our levels or cutscenes.

After textlessness and transience, a big driving force behind our menu design was incorporating game elements. For example, a quick description of our game’s mechanics might read like “things change when they’re in shadow”. So, wherever possible, we wanted to have a menu where things changed in shadow. The only place where we had the freedom to do something like this was in the level select menu. We thought about it a bit, and ended up with this beauty:

LevelSelect

This idea came up after about a million attempts at a menu design that showed off our mechanics a bit, but I think it was worth it. It’s pretty subtle, and uses a relatively standard swiping interaction.

Implementation

For those of you looking to make your own games, or just curious what our process was, lets take a look at how we actually brought these menus to life.

This is an area of development that really benefited from our three-phase process, in which we made a demo version of the game, and then started over when we began on the full game. This allowed us to iterate on our first approach to implementing the menus, without having to go through and update the existing menus. There are three interesting things that we did to create these menus.

Splash Screen and Pause Menu

In the demo version of the game, we created a pause menu prefab, and made an instance of it in each level. That way, we could update the prefab, and it would apply to every level. Seems pretty cool, right?

pausemenu

Because Where Shadows Slumber isn’t reflex-based, it can continue to play in the background!

While this is a pretty good pattern, and we’ve used it for a lot of other things, it didn’t really work for menus. The biggest reason for this was that we found ourselves going through every single level to update the individual menu objects with small, level-specific changes. While this might work for the demo, which only had ten levels, it’s a lot more work for the final game, which will have 38 levels.

Rather than have a menu object in each level, we decided to have a single menu object that persists throughout the entire game. After all, the menus themselves don’t change much from level to level. This is where the splash screen comes in – when the game loads up, the first scene is always the splash screen. This scene has the single menu object, and we simply tell Unity to allow it to persist from scene to scene (using DontDestroyOnLoad()). Any changes that need to be made to the overall menu text are made per level, as the level is loaded.

Level Title Cards and Translation

One part of the menu system that often gets overlooked during design is translation. For example, we decided to provide different languages for the demo, but we didn’t consider it or add it in until close to the release. This left us with a half-hearted translation system that was hard to update.

titlecard

I don’t think we need outside translators – my skills should suffice

The second time around, we decided to think about translation from the beginning of menu implementation, and we were determined to come up with something easy to work with. What we realized was that, for a foreign language, all text should be loaded from somewhere else – why should English be any different? Instead of creating an English menu and then applying translations, we started with an “empty” menu, and used our translation system to populate it with whatever language we wanted, English included! This forced us to take translation into account much earlier – so we can be much more sure that our translation system will work nicely with our menus.

But what does that translation system look like? Pretty much all of our other scripts are given values through the Unity editor. We did this for translation as well in the demo, and it was a complete disaster – even with our low-text menus, there was still a lot to add! We realized pretty quickly that we didn’t want to include the translations as part of the Unity scenes – we decided to have them loaded in separately, using JSON.

JSON, or JavaScript Object Notation, is a pretty cool file format used to organize values into a set structure. By storing all of our menu text (and translations of that text) in a JSON file, we can pretty easily read it into the game as it’s loading, thus allowing us to populate menu text objects with the correct language. It’s easy to read, easy to backup, and easy to update (unlike the Unity editor script fields), which makes it perfectly suited to this type of use-case.

json

A small sample of our JSON

The end process is pretty simple – when the game loads, parse the JSON file (which has all of the game’s text in “every” language). During the splash screen, where the menus are created, populate their text fields with the correct text from the JSON file. If we need to update the text, it’s as simple as changing the text in the JSON file, and everything just works!

The Level Select Menu

While the other subsections here describe ways that we learned from a bad implementation to make a good one, the level select menu is just a cool menu design.

Whille toying with menu ideas, Frank created a few of these “world tableaus”, and we knew that we wanted to have them in the level select menu. The coolest thing about them is that they aren’t just textures – they’re 3D scenes, which allows us to give them subtle movement (this kind of effect really helps make a game look “polished”). The question becomes – how can we display these scenes in such a way that they can interact with each other in two dimensions, while acting as completely separate scenes?

Unity has a pretty awesome feature called a RenderTexture, which allows a texture to display the live view of a Camera object (for the curious among you, that’s how you could make a CCTV screen or a mirror in a Unity game). Using a RenderTexture basically allows us to “flatten” the moving tableau scene into a moving texture, which we can then manipulate as we please. And, as it turns out, it pleases us to use math and angles to create the “sweeping shadow” effect.

You see, I’m a pretty big fan of math on the whole, and this was a perfect place to apply some trigonometry. Using complicated concepts (like “sinusoidal”, and “minus”), I came up with an algorithm that  would put two RenderTextures and a shadow triangle together in such a way that it created the desired effect:

Level Select Transition

theta = (3 * atan(h / 2x) – atan(h / (2 * (x + w)))) / 2

What you’re seeing here is that each RenderTexture is angled (and stretched appropriately), and then positioned in such a way that the line where they cross is exactly covered by the moving shadow. This gives the illusion of the menu behind the shadow magically changing from one image to the other.

This menu is my favorite part of the menu system, because it’s the most interesting, both from a technical, implementation perspective, and from an outside, aesthetic perspective. That said, I think we ended up with a pretty sweet menu system all around, thanks in no small part to our past failures in this area.

Looking Ahead

Unfortunately, no part of the game is ever really done. The menus are in pretty good shape, but there’s still some polish we need to do, and I’m sure there will be small changes we want to make as we move forward. In fact, this was one of the more important concepts behind a lot of our decisions – any changes we want to make should be pretty easy!

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

Hopefully you enjoyed this peek at the menus for Where Shadows Slumber! If you have any questions about our menus, 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, join the Game Revenant Discord, 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.

Just Do It

No, Where Shadows Slumber hasn’t received any funding from a mysterious shoe company. Rather, I want to discuss an aspect of working on a personal project that I’ve seen a lot of people struggle with, and that I’ve had trouble with in the past. Yes, this post touches on a few of the topics that I talked about in a previous blog post about ‘drive’, but today I want to focus more on a specific facet of the process: forcing yourself to work on something that you don’t want to.

Every project is difficult. In particular, every project begins to drag as you get closer and closer to the end. You find it more and more difficult to keep working on it. At the beginning of your project, there’s a whole bunch of stuff you’re excited to work on. As you reach the end, you find that you’ve done all of the fun things, and the only things left are boring tasks and difficult decisions. This is the point where you’re really being put to the test, and in this situation, I have one piece of advice for you – buckle down and just do it.

Let’s take a quick look at the different kinds of things you should just force yourself to do, and how to actually do so.

 

Doing Things You Don’t Want to Do

The most obvious kind of thing you don’t want to do is, well, something you just don’t want to do. These things are different for everyone, and come up for various reasons. For me, these are the cleanup/polish kinds of tasks. For other programmers, it might be the mathy, trig-related stuff. For an artist, maybe it’s animating hands or something (I hear that’s really hard…). Whatever it is, everyone has something they consider ‘dreg work’, and those tasks start to pile up.

taxes

Tax  season is coming up, and I’m already putting it off

If you’re anything like me, when you come upon one of these tasks, you briefly consider doing it, and then you move on to something easier or more interesting. After all, there’s no shortage of work in your project! This happens a lot with teams as well, especially less organized teams – “if I go work on something else instead, somebody will probably take care of this by the time I get back to it”.

Unfortunately, these two base assumptions fall apart when it comes to indie game development (or any similar venture). In most cases, your project has to come to an end eventually, which means that you can’t simply keep putting these tasks off. And with a smaller, indie-sized team, it’s unlikely that you can just put that responsibility on someone else. It’s pretty cool to be the arbiter of your own success by taking charge of your own game development project, but it also involves other responsibilities.

I know quite a  few people who check their email regularly – until they see that one email that prompts them to do something. They know they have to do it, but they simply don’t want to. Rather than just doing it, getting it out of the way, and having some peace of mind, they close their email and proceed to ignore it for the better part of a week. Inevitably, this doesn’t cause the task to go away, but just gives them less time to do it, and a boatload of stress while they’re avoiding it anyway.

The bottom line is that these tasks must be done – you’ll come across them, and you’ll simply have to do them. The most important thing is to have a positive attitude in these instances. You come upon a task that you don’t want to do – acknowledge that you have to do it, take a deep breath, and just get started. Once you’ve begun, you’ll probably find that it’s not as bad as you thought – simply starting the task is usually the hardest part. And hey, if it ends up being an awful task, at least you got it out of the way!

 

Committing to an End

Another area where it’s very important to embrace a “just do it” attitude is when it comes to actually finishing your project. As an indie game developer, it’s perfectly natural to be apprehensive of your eventual release. After all, you’re just a small group of people (or even just one!), but your game will still have to compete with games made by giant studios. It makes sense to want to make sure your game is absolutely perfect before committing to a release.

The problem with this plan is the use of the word perfect. Your game will never be perfect. In fact, your game will never even be “good enough”, especially considering your own perfectionist perspective. Waiting for perfection leads you to a phase of endless polish, which can delay your project for years, or even indefinitely. The only thing worse than releasing an imperfect game is not releasing one at all.

There’s a pretty common attitude of “I’ll release it when it’s done”, or “I’ll know when I get closer to the end”. While these make sense at first blush, and are good mentalities to have toward the very beginning of a project, they quickly turn against you, causing your project to become more and more delayed.

duedate

Red marker. That’s how you know it’s serious.

Unfortunately, as introspective as we may consider ourselves, there’s a significant amount of stuff going on under the hood that we’re not even aware of. One of the more annoying of these is that, if there’s no “due date” for your project, your brain will subconsciously de-prioritize working on it. Similarly, there’s a well-known adage that work expands to fill the space its given – if you have twice the time to do something, you’ll just subconsciously work half as hard at it. For example, at the end of November, we were on schedule to release Where Shadows Slumber by April. We recently pushed that date back by a few months, without increasing the project’s scope. You would think that this would give us some breathing room, but the new “deadline” feels like it will somehow be even harder to meet!

Managing the timeline of an entire project is an incredibly difficult task. One important piece of advice I would give would be to pick a target release date. Even if it’s not public, picking a date, committing to it, and doing everything you can to meet it will definitely help you prioritize the work you’re doing, frame it appropriately, and avoid the project stretching into infinity.

Don’t get me wrong, you shouldn’t choose a release date willy-nilly; you should realistically estimate when you can complete the project, and choose accordingly. Similarly, there’s no need to have a specific end date in mind when you start the project. Your target date is a great motivational tool, but it only works if it’s at least somewhat accurate. Even if you miss your release date (or realize you’re going to, like we did), it’s not a problem. You just have to reassess the work that’s left, and choose a new date. As long as you don’t keep extending the project, you’ll be fine.

 

Decision-Making

While there are tasks that you don’t want to do because they’re difficult or time-consuming, there are other reasons to not want to do something. In particular, making decisions is a real sticking point for a lot of people. If you implement something incorrectly, you can always redo it, but many of the decisions you have to make for your game have an irreversible effect. This is really daunting, and since decisions themselves don’t take a lot of actual physical effort, the natural response is to simply put off making the decision for a bit.

DecisionMaking

When faced with a choice between success and failure, I hope you’ll always choose Where Shadows Slumber!

This is similar to the “end date” discussion above. While many of these decisions are very important and require a great deal of thought, they still have to be made. It’s important to never forget this fact, as decision paralysis is another great way to destroy your game.

When you find yourself facing one of these decisions, make sure you don’t back off, at least not repeatedly. You have to make the decision eventually, so you might as well do it now. In fact, in the case of some difficult, important decisions, you might even lock yourself in a room until you’ve made the decision. That’s exactly what we did when picking out the name for Where Shadows Slumber – Frank and I sat down, and neither of us was allowed to leave until we had picked a name. It ended up taking a few hours, but we had managed to nail down the answer to a very difficult decision.

 

Just Do It

There are a lot of places in game development where you find it hard to do what you have to do. These moments are gateways to stagnating development and endless work. When the time comes, you often must act. Don’t make half-hearted decisions or poor implementations, but really force yourself to do what needs to be done. Just do it.

 

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

If you have any questions about any of our development struggles, 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, join the Game Revenant Discord, 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.

Unity 2018!

For those of you who haven’t been keeping up with current events in the indie game development space, there’s something really important that’s happened recently that you should probably know about.

It’s 2018!

Which leads me to another topic that we can spend some time discussing – Unity 2018!

 

Unity

Before we talk about Unity 2018, let’s discuss Unity itself. Unity is the game engine in which we’ve been developing Where Shadows Slumber for the past two and a half years, and even longer ago, when we were working on SkyRunner. Developing in a game engine makes things a lot easier for the little guys like us, because we don’t have to worry (as much) about things like platform-specific dependencies, rendering pipelines, mipmap implementations, etc. Without having to worry about that nitty-gritty stuff, we can spend our time focusing on the more grandiose parts of the development of WSS.

So the question is – how has working with Unity been?

1200px-Unity_Technologies_Logo.svg

Unity!

Overall, Unity is awesome. It has somehow managed to find the right balance between an engine that you could use to make a AAA game, and one that you can use in a small, bureaucratically-challenged team. This alone is a great reason to use Unity – compared to using more complex engines like Unreal, it’s much easier to get up and running from scratch.

Of course, there are trade-offs, and this is a particularly big one. In order to avoid inundating newer users with game development intricacies and high-level concepts, Unity does a lot of that stuff for you, behind the scenes. While this is awesome in a lot of cases, there are some cases where it can be more of an issue. Imagine you’re an experienced game developer, with a sizable team, who wants to do something very specific in the backend. There’s a decent chance that Unity will have hidden that part of the engine from you, or at least made it difficult to interact with.

This tradeoff is, at its core, the reason that you would or wouldn’t want to use Unity. The next most important feature is the ease with which Unity allows you to develop on multiple platforms. All of your development is platform-agnostic, and you only choose the platform as you’re compiling. Is your Android game a success, and you want to build it for PC? Simply hit a different button, and Unity takes care of the rest. I don’t have too much experience with other engines, but this seems to be a place where other developers give Unity a lot of credit, and I think it’s deserved. I can’t imagine having to go through all of the development we’ve done multiple times for different platforms.

Beyond these bigger points, there are a few other things that might sway you, though they’re probably a little less important:

  • Unity is very UI-based, which means that it might be a little annoying for a hardcore programmer, like myself, whereas this probably makes it easier for someone with less coding experience, like Frank.
  • Unity is a sort of one-size-fits-all solution, whereas some other engines are ready-made to create certain types of games. For example, Unreal has good support for creating FPS games. If I were to make an FPS game, using Unreal would probably give me a bit of a head start on Unity.
  • The only language Unity supports is C#. C# is a pretty awesome language, but for those of you who hate C#, or strongly-typed languages in general, it may take some adjusting.

Again, I want to say that Unity has been great for us, and I would probably use it again if I were to start another game. Frank and I wouldn’t have gotten to where we are with Where Shadows Slumber if it weren’t for Unity.

 

Unity 2018

I mentioned earlier that Unity does a lot of stuff for us, and I specifically brought up rendering pipelines. The danger of using a game engine (that you didn’t make yourself) is that other people are making decisions for you, and those decisions are set in stone to a certain degree. On one hand, we didn’t want to mess with the collision system, so we were glad to have it. On the other hand, we ended up in a position where we did want to mess around with the rendering pipeline, and we weren’t able to.

Enter Unity 2018.

image5_rs

The Unity UI, blatantly stolen from one of their blog posts.

I normally don’t pay too much attention to the ins and outs of the various updates that Unity makes. They’ve been marching out updates, both major and minor, for a while now, and we’ve just been going with the flow. Unity 2018, however, has managed to catch my eye. Unity recently released a blog post describing the updates they’ve been making to graphics and rendering in Unity 2018, and I have to admit that I’m pretty excited about it.

As I mentioned before, Unity does a good job of riding the line between too-complicated-for-new-users and not-powerful-enough-for-power-users, and the updates described for Unity 2018 somehow manage to play to both sides. If you’ve ever held a conversation with me about Unity and Where Shadows Slumber, then you know that I’ve been struggling with getting shadows to render the way I want, while also maximizing the efficiency of the rendering pipeline. Fortunately, Unity 2018’s focus on graphics and rendering has provided two huge features in this area, one for each of the two camps.

Scriptable Render Pipelines is the feature that I’m excited about, as it’s the feature aimed toward the entrenched coder. Rather than using the hard-coded rendering pipeline that we’ve been wrestling with for the past two years, we can create our own rendering pipeline that does exactly what we need it to.

“Programmers can now write custom renderers tailored specifically to their project.”

This is a huge boon to us, and to game developers everywhere. Rather than hacking together a shader that uses Unity’s shadow-mapping inefficiently, we can (hopefully) create a rendering pipeline that performs shadow-mapping exactly how and when we need it. This should result in more efficient rendering, along with less headache while writing shaders.

Shader Graph is the other great feature Unity 2018 will have, and is targeted toward less code-inclined users. Unity provides a standard shader with a bunch of options, so you can create the materials you want. However, if you need more customization than the standard shader provides (like we do), you’re suddenly thrust into the depths of shader-writing. With a masters degree in computer science, I’ve been just barely keeping up with writing our shaders, and there’s no way that Frank would have been able to do it. This is really a bummer, as the artist tends to know a bit more about the “look” they’re trying to get.

“[I]t’s simple enough that new users can become involved in shader creation.”

Unity 2018’s Shader Graph changes this – rather than writing complex shader code, Unity exposes a simple interface for creating shaders graphically. This would allow an artist with no coding experience whatsoever to build a custom shader to display things exactly as they want – giving the artist the control they need over the “look” of the game, and allowing the programmer to focus on the game itself.

shadergraph

A sneak preview of Unity 2018’s Shader Graph UI

I’m sure that Unity 2018 comes with quite a few quality-of-life updates, as well as some other new and interesting features. For me, however, it’s all about those rendering updates!

 

Beyond Where Shadows Slumber

A friend of mine recently asked if I would use Unity for my theoretical next project, and if I would recommend it to someone just starting on a game. The answer I gave him is one that applies to every question – it depends. In fact, it mostly depends on the factors described in the first section.

Overall, I’m inclined to say that I would use Unity again. After over four years, I’ve come to know it pretty well. It’s powerful, and allows you to create and iterate pretty quickly. That said, there are some exceptions; I would probably pass on Unity for my next project, or at least do some more research, if:

  • I had very specific backend/optimization requirements
  • I were working with people who had a lot of experience with a different engine
  • The scale of the game were much bigger
  • The game involved a lot of networking/server concerns

There are probably other factors that come into play – basically, it pays to do some research before you dive in. I would recommend Unity, but more than that, I would recommend knowing what you’re getting yourself into. There’s nothing worse for your game than getting halfway through it in an engine that won’t work for you in the end.

If you’re anything like me, at this point the word “Unity” no longer sounds like a word. I’m gonna take that as a sign and wrap this post up; I hope I was able to answer any questions you might have had about working with Unity, and that I got you pumped for Unity 2018!

 

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

If you have any questions about working with Unity, 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, join the Game Revenant Discord, 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.

Drive

If there’s one thing an indie game developer needs, it’s drive. The competition is fierce, the process is difficult, and we even have to deal with our day jobs on top of everything else.

In order to get our games to market successfully, we have to do a lot of stuff right, make a lot of difficult decisions, and put in a lot of hard work. In order to accomplish any of these things, the first thing you need is the urge to make a game, the drive to make your dream become a reality. But what exactly is drive?

Drive
drīv
noun
  1. an innate, biologically determined urge to attain a goal or satisfy a need.

Drive is the internal force you feel that causes you to create something. Drive is forcing yourself out of bed hours before you have to get to work, just for a chance to work on your game. Drive is spending the evening testing the performance of your pathfinding algorithm rather than playing Rocket League. Drive is a lot of things, but I think of it as three core parts:

  • The urge to work on a project, including the confidence that it will succeed – This is where drive starts. It’s impossible to follow any large project through to the end if you don’t care about it and believe in it.
  • The dedication to work on your project, despite any sacrifices you might have to make – This is how drive shows itself, and is the trait most associated with the term. When you want to complete something badly enough, you force yourself to work on it, even (and especially) when you don’t want to.
  • The willingness and ability to make difficult decisions about your project – This is less often associated with drive, but I think it’s perhaps the most important point. Choosing to trim features or making an irreversible development decision is very difficult, but it has to be done. Your project will suffer if you don’t make decisions, and you have to understand and embrace that.

I’ve seen a lot of indie game development projects suffer due to a lack of drive. The most obvious ones are the games that were never finished because development petered out. Slightly less obvious are the games that take over half a decade to develop because the developers aren’t willing to sacrifice parts of their games, or the games that do come out, but are a little lackluster because of prioritization and decision-making issues. I even know quite a few people who are much more qualified to make a game, but simply haven’t felt the drive to do so.

Frank and I, fortunately, do have a good bit of drive, and we’ve been very careful to get as much use out of it as possible. At the beginning of 2017, we had picked an internal target release date of March 15, 2018, and I’m pretty proud to say that, up until about two months ago, we were on target to meet that date.

Unfortunately, no amount of drive can get you through everything.

 


 

So What Happened?

A few months ago, my fiancée, Molly, went to see a doctor about a lump she had felt in her neck. Long story short, she was diagnosed with cancer this past November. I won’t go into all the details here (if you want to find out more, you can read her blog about the experience here), but suffice it to say that it’s really turned our lives upside down.

chemo

“In sickness and in health”

It’s pretty difficult for me to think of myself as “lucky” in any sense right now, but I know that things could have been much worse – we caught it early enough that it’s still curable. She is currently halfway through her four months of chemotherapy, which means she should be cured by the end of March.

While it’s not as bad as it could be, it’s definitely not good. Molly is the most important thing in my life, Where Shadows Slumber included, and I will continue to do everything I can for her. She has been endlessly supportive of the development of WSS, despite how much time I commit to it, and I intend to be just as supportive of her. Unfortunately, on account of my already-busy schedule, that means some things are going to suffer.

 

Development-Hell

Development shot of the first Level of the Jail.

What This Means for Where Shadows Slumber

If you read this blog regularly, you may have noticed that I haven’t been contributing as much as usual – Frank has stepped up and kept the blog posts flowing. However, what you most likely haven’t noticed is how little I’ve been able to contribute to the project itself. This trend will continue through the end of March – I’ll still be working on WSS as much as possible, but that amount will be far less than it has been over the past two years.

gitcontributions

Cancer and Commits are inversely proportional

What this means is that our targeted March 15 release date is no longer feasible, and we’re in a position where we have decided to push the release date back a few months. We still don’t have a public release date, but you should know that we will be releasing in Quarter 2 of this year rather than Quarter 1.

While this is the biggest concrete reason to push back the release date, to be honest, everyone on the team is breathing a sigh of relief. We are all very determined to finish this project in a timely fashion, and we all have the necessary drive to do so, but we also know that the extra time will help us to make Where Shadows Slumber the best that it can be. I know Frank wanted more time to work on polishing up the art, Noah and Alba mentioned that they could implement some cool sound stuff if we had more time, and I could definitely afford to put more work into optimization.

 

Development-Snow

Development shot of one of the Levels in the Summit.

 

Moving Forward

Despite all of this, I still have the drive to finish Where Shadows Slumber. Aside from the shift in timeline, our plans for the game haven’t changed, and our goals seem as achievable as ever. Hopefully, come April, this will all be behind us, and the glorious future of Where Shadows Slumber will be the next thing on the horizon.

 

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

If you have any questions about our timeline and how it has changed, 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, join the Game Revenant Discord, 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.

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

Hacks Versus Designs

I remember back in the day, when computers and programming were first becoming somewhat ‘cool’. Back then, the coolest thing you could be in the computing world was a ‘hacker’. Hackers were awesome renegades who could tear down opposing systems using nothing but their superior intellect. Being able to hack was one of the best skills you could have. Now, after studying and working in computer science for a while, the term ‘hack’ has taken on a very negative connotation.

When you’re writing code, there are several things that you’re aiming for. The two broadest and most important of these are:

  1. The code works – it does what you intend for it to do.
  2. The code is good – it’s efficient, understandable, and easy to use/improve.

It seems like these two things would go hand-in-hand, and for well-designed code, that is often the case. However, the road to that ‘well-designed’ code is often fraught with terrible, terrible code. So, what’s the intrinsic difference between these two goals, and how does it lead to bad code?

 

boolean

Hack First, Ask Questions Later

When you’re working on a large, intricate system, and you need to add something or make a change, these two goals lead to two different types of results – a hack, or a design:

  • A hack is a piece of code with only the first goal in mind – you’re just trying to ‘make it work’. You don’t want to put a lot of thought or time into the implementation, you just want it to work.
  • A design has both goals in mind – you’re spending time to come up with a good solution. You’re willing to work a little harder to end up with a more robust, long-loving solution.

Designing a solution to a task leaves you with good code. It’s easy to understand, easy to use, and easy to update. The algorithm makes sense, not just in terms of “does it do what I want”, but also in terms of “does it make sense with the theory behind it”.

Looking at these two descriptions, it’s pretty easy to see – designs are better than hacks. So why would anyone ever want to use a hack to get something done? There are a few reasons.

Designs take more time. You have to come up with a solution, consider its long-term viability, consider how it will interact with every part of your system, present and future, tweak it accordingly, and make sure that it still matches the theory of your application. A hack, on the other hand, involves simply coming up with a quick and dirty solution, and implementing it.

Designs require deeper understanding. In order to fully understand the impact of your newly-designed code, you have to completely understand the current state of your application, remember all of the assumptions you made when coding it, and ensure that your new stuff won’t interfere with any existing stuff (Note that this is much harder to do on a larger team, as there are areas of the code you may not be as familiar with).

Designs are often much larger in scope. When designing a solution, it will often involve creating a ‘system’ or ‘engine’ of sorts. Not only does this take longer to think through and implement, but it also opens the door to a lot of subtle interactions between systems. Hacks are (usually) much more localized – “I’m gonna make this hack here, but I won’t use it in other places”.

You don’t want to spend a lot of effort on code that will be replaced eventually. This is really just a combination of the above points, but it’s an important reason why hacks exist. If you have to update a small piece of code, but you know that you’re going to come in and change the whole thing next month anyways, why would you put a lot of time and effort into designing a solution when a quick, hacky fix will do the trick?

Looks about right Cropped

This is what happens when you leave hacks in your code!

 

Here’s An Example

Let’s say you’re you’re working on a pretty simple game in a pretty simple game engine, using a pretty simple programming language (hint: this means I’ll be using pseudo-code rather than real code). You’ve got your character on the screen, and you want to make him move back and forth along some flat ground whenever you hit an arrow key. You might start out with something like this:

if (keys.leftArrow) {
  dudeGuy.position.x -= 10;
}

if (keys.rightArrow) {
  dudeGuy.position.x += 10;
}

Pretty simple and straightforward – if you’re pressing the left arrow key, move your dudeGuy to the left, and if you’re pressing the right arrow key, move him to the right.

So, you use this code for your movement, and it works, and you continue working on your game. Then, suddenly, you have an epiphany – what if your dudeGuy could jump? You add a variable and hook it up:

int jumpingTimer = 0;

...

if (keys.spaceBar && jumpingTimer == 0) {
  dudeGuy.position.y += 30;
  jumpingTimer = 3;
}

if (jumpingTimer > 0) {
  dudeGuy.position.y -= 10;
  jumpingTimer--;
}

As you continue making your game, you design some levels where you realize that you want the gravity to be less strong, so you have to account for that:

float gravity = 10;

...

if (keys.spaceBar && jumpingTImer == 0) {
  dudeGuy.position.y += 30;
  jumpingTimer = 30 / gravity;
}

if (jumpingTimer > 0) {
  dudeGuy.position.y -= gravity;
  jumpingTimer--;
}

Then you realize that your back-and-forth movement looks pretty choppy, so you decide to add some ‘smoothing’, so your dudeGuy speeds up and slows down:

int movingLeftTimer = 0;
int movingRightTimer = 0;
int jumpingUpTimer = 0;
int jumpingTimer = 0;
float gravity = 10;

...

if (keys.leftArrow) {
  if (movingLeftTimer < 3) {
    movingLeftTimer++;
  }
} else if (movingLeftTimer > 0) {
  movingLeftTimer--;
}

if (movingLeftTimer > 0) {
  dudeGuy.position.x -= 10 / (4 - movingLeftTimer);
}

if (keys.rightArrow) {
  if (movingRightTimer < 3) {
    movingRightTimer++;
  }
} else if (movingRightTimer > 0) {
  movingRightTimer--;
}

if (movingRightTimer > 0) {
  dudeGuy.position.x += 10 / (4 - movingRightTimer);
}

if (keys.spaceBar && jumpingTimer == 0) {
 dudeGuy.position.y += 30;
 jumpingTimer = 30 / gravity;
}

if (jumpingTimer > 0) {
 dudeGuy.position.y -= gravity;
 jumpingTimer--;
}

And,  before you know it, with only a few changes to what we were trying to do, we end up with a piece of code that’s incredibly messy, almost impossible to understand, and prone to bugs and off-by-one errors. Honestly, I just wrote this thing, and I have no idea what it’s supposed to be doing.

Now, this example is a bit of an esoteric one, just to prove a point. However, it is definitely not the worst code I’ve ever seen (or written), and that’s saying something. What should we have written instead? Well, if you couldn’t guess, the above code is an example of a hack (or a number of hacks put together). Rather than examining what it was we needed in the long run, we repeatedly implemented something that did the job in the short term. So, let’s make a design for this use-case, and think about what we need overall.

We want to be able to move left/right, jump, have different values for gravity, and have smoothing on our movement. This sounds a bit like actual physics, so lets steal some important concepts from them – acceleration and deceleration. We’ll determine some rules that match our design, modify the dudeGuy’s acceleration in each direction based on those rules, and then move his position all at once:

float maxSpeed = 10;
float acceleration = 3;
float jumpAcceleration = 10;
float gravity = 3;
float friction = 5;
float minY = 0;

float vx = 0;
float vy = 0;

...

// If the left arrow key is down, accelerate to the left
if (keys.leftArrow) {
  vx -= acceleration;
}

// If the right arrow key is down, accelerate to the right
if (keys.rightArrow) {
  vx += acceleration;
}

// If the spacebar is down and the dudeGuy is on the ground, accelerate upwards
if (keys.spaceBar && dudeGuy.position.y == minY) {
  vy += jumpAcceleration;
}

// Accelerate downwards for gravity
vy -= gravity;

// Decelerate for friction
if (vx > 0) {
  vx -= friction;
} else if (vx < 0) {
  vx += friction;
}

// If we're going to fast to the right, slow us down to the max speed
if (vx > maxSpeed) {
  vx = maxSpeed;
}

// If we're going to fast to the left, slow us down to the max speed
if (vx < -maxSpeed) {
  vx = -maxSpeed;
}

// Update the dudeGuy's position based on our current velocity in each direction
dudeGuy.position.x += vx;
dudeGuy.position.y += vy;

// If the dudeGuy is below the ground, move him up to ground level
if (dudeGuy.position.y < minY) {
  dudeGuy.position.y = minY;
  vy = 0;
}

While we have a similar number of lines of code here, it’s much clearer what’s happening on each line. Every block serves an easy-to-understand purpose, and making changes to the ‘rules’ of movement is very easy. There are a lot of different ways to improve this code, depending on your game’s overall design, but this is a decent, and most importantly simple, place to start.

Another important feature of this piece of code is that it is well documented. Every block is pretty small, but it still has a comment describing the purpose of the block. This is an extremely important part of programming in the context of larger systems – you want to make sure that you (or anyone else) can quickly understand what your code is doing, especially in complex cases. Even though some complex logic might seem simple to you, it’ll definitely seem more difficult when you come back to it in 6 months!

 

A Necessary Evil

Unfortunately, hacks are a necessary evil. While I would love to only ever have to deal with and implement beautifully-designed code, that world doesn’t exist. There’s always a timeline, there are always changing assumptions and new features, and there’s always someone who wants it to be finished yesterday. Inevitably, you’re going to have to write some code quickly, implement a feature that’s likely to change, or come up with a simple ‘solution’ to a difficult problem. In cases like this, you’re forced to use a hack.

Hack

I mean, it works… technically…

It’s not all bad, though. While hacks in general are pretty bad, they can be manageable if you make sure to use them correctly. In fact, I would be willing to bet that any system currently in production (of a certain size) contains quite a few hacks. There are certain qualities that hacks can have which make them a little bit more manageable, and you should try to aim for them whenever you find yourself implementing a hack:

  • Understandable – It’s important that, whatever your hack is, anyone else looking at the code can understand what you were trying to do, and how your hack works. This means leaving a lot of comments around your hack, as well as simplifying the logic as much as possible.
  • Localized – If you have to hack something in, you want it to only be in one place. Every time that code path is used, there’s a chance that something will go wrong. If your hack only touches a small part of your system, then its negative effects will be much less noticeable. This means that frequently-used code paths should never really have hacks in them, while hacks in rarely-used code paths are more acceptable.
  • Known – This is, to me, the most important part of making a hack. If you hack something in and then forget about it, when your system starts failing, you won’t know where to look. If you make sure you remember it (by writing it down somewhere and then telling every person you know), then you’ll know where to look if something goes wrong. On top of that, you’ll always have that hack in the back of your mind, so you’ll be more likely to think of a good design to replace it.

If you follow these guidelines and make sure to try to go back and fix them, then putting hacks into your code won’t end up destroying you.

I hope this was helpful to those of you just starting out in game development – or anything which involves designing complex systems! For those of you who already know a little something about computer science, I hope this at least reinforced your burning hatred of hacks!

 

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

If you want to know more about how to deal with hacky code, or what kind of hacks are in Where Shadows Slumber so that you can exploit them, 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.