Tag Archives: jack

Monument Valley 2 and Its Implications

Posted on by

On Monday, Apple and ustwo games nonchalantly made an announcement that could forever change the development of Where Shadows Slumber. If you haven’t heard (or figured it out from the title), then I’m glad I get to be the one to tell you – Monument Valley 2 has just been released for iOS devices, with Android coming “soon”!

If you’ve ever played the original Monument Valley, then you’ve probably noticed that it was a big inspiration for Where Shadows Slumber (in fact, you might remember that I mentioned something to that effect in my first blog post). Monument Valley is one of my favorite games of all time, and I’m super excited to be able to return to that world for another round!

As awesome as this announcement is, it’s also a little bit scary. Monument Valley 2 is gonna make a big splash, and people are going to be paying attention to it. The development, production, and eventual release of Where Shadows Slumber will all be happening in its wake, and so this announcement is very important to the future of Where Shadows Slumber.

How does this announcement affect our development, you ask? Well, let’s take a look!

 

There Can Only Be One

Monument Valley was awesome. I mean, it changed the face of mobile gaming as we know it. It was genre-defining and laid a lot of ground for future games like Where Shadows Slumber.

The problem with using a game as inspiration is that your game becomes pretty similar to that game. Since Monument Valley was such a hit, that’s not really a bad thing. Until you consider the fact that two very similar games are inherently competitors. We feel pretty confident in Where Shadows Slumber, and we felt that four years would definitely be enough to set us apart. A new Monument Valley game really changes the equation, for a number of reasons.

screen_263x350_2017-06-06_08-24-37

Ro vs. Grongus: Deathmatch

The first reason is pretty obvious – there are only so many people buying puzzle games. A giant like Monument Valley 2 takes up a lot of that demand. If Joe Puzzlegamer pulls up to the App Store and wants to get an artsy puzzle game, he’ll have a lot of choices. Even if he only had two choices, which would he choose – Where Shadows Slumber or Monument Valley 2?

Monument Valley 2 has a pedigree. It has a wildly successful predecessor. It was made by a studio with a real budget, decently-sized teams, and the know-how to bring a successful game to market. Where Shadows Slumber is awesome, but we’re just two random guys with little money and even less experience. Even if that’s not how we see it, that’s how everyone else will. Monument Valley 2 is the clear choice for the random outside observer.

In addition to losing out on potential sales, there are other things we could lose to Monument Valley 2. For a team without a large advertising budget, one of the best ways for us to get publicity is through conventions and awards. With Monument Valley 2 crowding the beautiful Unity-based puzzle genre, we could also lose chances to attend conventions and win awards. Again, people will have to choose between us and them. Will Unity invite us to represent them at an event? Will Apple shower us with promotions? Will we be anyone’s pick for best puzzle game? Probably not, if they can get Monument Valley 2.

 

Puzzle Mania

While there are some negative takeaways to Monument Valley 2, there are definitely quite a few positives (in addition to the fact that we have another awesome game to play). As they say, a rising tide lifts all boats.

When Monument Valley first hit the mobile gaming scene three years ago, it made quite a big splash. People absolutely loved it, and they clamored for more – I know when I finished Monument Valley, I wished for nothing but more levels. Imagine if we had been able to release Where Shadows Slumber 8 months or so after that – just when people are done with Monument Valley, but still want a similar experience, we provide them with exactly that!

Monument-Valley-2-Main-by-Ustwo-games

Bringing people back to puzzle games

We’re hoping for a similar situation to unfurl here. People will play Monument Valley 2, and it’ll get their brains working. They’ll (presumably) love the puzzles, the art, the brooding atmosphere. They’ll be all warmed up to the genre, and they’ll be on the lookout for anything similar. We’ll be ready to pounce on that crowd, and hopefully it’ll help us release into a bit more hype than we might otherwise.

Basically, we’re hoping that Monument Valley 2 will revitalize the moody puzzle game market. Not to sound too utilitarian, but we plan to use Monument Valley 2 as a sort of springboard to success!

 

Timing

There are a few things about this announcement that could be bad for Where Shadows Slumber, as I mentioned, but I think that there is an important factor worth mentioning, and that is the timing. We’re planning on releasing Where Shadows Slumber in early 2018. So, all things considered, I think this timing is just about perfect for us. If Monument Valley 2 had to be released sometime soon, now is probably the best time.

timing

Perfect timing.

If Monument Valley 2 were to be released a month or so after Where Shadows Slumber, we wouldn’t even stand a chance. As soon as people were starting to get excited about our game, a much more acclaimed game would come along and steal all our thunder! A similar story plays out if we release shortly after them – our release simply goes unnoticed.

So why is this the best time? Wouldn’t it be better if they had released a long time ago, to keep our release as far away from theirs as possible? While that makes a lot of sense, I think that Monument Valley 2 will inspire more interest in puzzle games overall, and eight months seems like a pretty good timeframe for the MV2 hype to die down, but for the puzzle fever to still be strong.

Additionally, the fact that Monument Valley 2 has been released in a different calendar year from Where Shadows Slumber works in our favor as well. A lot of awards are of the form ‘game of the year‘, and Monument Valley 2 is a shoo-in for many of those awards. With our biggest competitor releasing in a different year, we won’t have to compete directly with them for ‘of the year’ awards. Not that we expect to win these awards, but it’s always nice to feel like you have a chance.

 

Changes To Development

So how does this actually change our development plans for Where Shadows Slumber?

Since the timing of Monument Valley 2 is working in our favor, we’ve decided that we’re going to stay the course. We’re still aiming for an early 2018 release, which we feel puts us far enough away from this release. If Monument Valley 2 announced their release in early 2018, we would have no choice but to push our release back a few months. As of now, we aren’t making any changes to our schedule, but we’re definitely keeping our eyes open – if they release an expansion of some sort in early 2018, we might have to reconsider our own release date.

Since Where Shadows Slumber was so inspired by the original Monument Valley, we’re also looking at this as an opportunity to be inspired again. People have, and will continue to make comparisons between our game and Monument Valley, but now they’ll have a newer, sleeker version to compare us to – we have to try and keep up! We get to see another take on the Monument Valley style of puzzler, and we get to see a bunch of new mind-bending puzzles. Perhaps some of them will strike inspiration in our hearts, and help us make Where Shadows Slumber that much better!

inspiration

Can you feel the inspiration?

On the other side of that coin, we’ll also be playing Monument Valley 2 and looking for anything that’s a little too similar to Where Shadows Slumber. If we find that one of our levels is very similar to one of theirs, we may have to change it – even though we didn’t steal it from them originally, that’s what it will look like to the outside observer. We want to be similar to Monument Valley, but not too similar.

 

Takeaways

Most of the above musings on the implications of Monument Valley 2 are pretty specific, and overall, they’re pretty far beside the point. This is one of the most exciting announcements I’ve heard in a long time, and I can’t wait to get my hands on the new game! That’s the biggest takeaway you should have from this post – no matter what the implications, I’m super excited, and you should be too!

 

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

If you finish Monument Valley 2 and are looking for more puzzle-y goodness, 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.

Progress Report

Posted on by

Frank and I have worked hard on Where Shadows Slumber, and we continue to do so every day. As a team of two, designing a game at our own whims, it’s very liberating. No one tells us what to do, and there’s no bureaucratic red tape forcing us to work on any specific part of the game.

Unfortunately (for us), that red tape does have an actual purpose. Without anyone telling us what to do, we have to figure out what to do! I just touted this as a good thing, but it’s also terrifying! How do we know if we’re doing the right thing? We’re trying to get to a release of a completed game, and we’re the ones who have to decide how to get there! With success comes ultimate glory, but any failure rests on our heads. Given how likely failure is in this industry, we have to make the right decisions at every point of the way. How are we planning on doing it?

Well, despite the fact that I just really scared myself with that last paragraph, we’re going to take a deeper look into what we’ve done so far, and what we’re going to do next, from a project planning perspective.

 

How Far We’ve Come

evolution

The evolution of Grongus

Frank and I are just two normal duders. (Note: technical term)

We’re also two normal duders who happened to be perfectly suited to approach a project like this. He has some sort of degree related to art and technology, and I have some sort of degree in computer science. We both have the resources to survive without depending on the income from what will end up being a ‘pet project’, and yet we’re both driven enough to dedicate ourselves to that project, even though we’re not dependent on it. We’re close enough to be willing to work together, but not so close that we just end up bickering the whole time.

When the idea for Where Shadows Slumber came up, we knew we had something awesome on our hands. We came up with  a plan, developed a schedule, and started working!

Now, that plan and that schedule have changed a lot in the past two years. Features have come and gone, level design has gone through a lot of iterations, and even our day-to-day process has changed. But, through this flexibility, we’ve managed to stay somewhat on-track. We’re still here, we’re still working on our game, and we’re still in a position where we can have a timely release.

Those of you who have never worked on an indie game are probably wondering why that seems like an accomplishment, while those of you who have are dying to know how we did it. And, if I had to choose a word to describe how we got here, it would be introspection.

in·tro·spec·tion
noun
  1. the examination or observation of one’s own mental and emotional processes.

What I mean by this is that we are constantly looking at our process, looking at what we’ve done, the mistakes we’ve made, and the road ahead. We have to asses our project as often and as accurately as possible, and we have to be completely honest with ourselves, if we want an accurate plan of action.

We’ve done this many times throughout development, and last week, we sat down and did the same thing again. So, let’s take a look at that process!

 

Where we are now

In my experience, when working on a game, there are usually three mindsets you’ll fall into:

  • ‘Future me will take care of that’ – This happens when your target release date is far enough in the future that the time left and the remaining tasks haven’t formed into a concrete plan, but you have so much time that you know you’ll be fine. This is often accompanied with phrases like ‘I’ll still have  plenty of time for X once I’m done with Y’. Be careful with this thought process – in my experience, you always have more work and less time than you think!
  • ‘I’m behind schedule, and I didn’t even realize it’ – This might be the most stressful mindset, but it’s probably the best one. This starts to crop up as your release date is no longer ‘in the distance’, and the enormity of your remaining tasks really hits you. You start thinking things like ‘I don’t know if I can finish all this work in that amount of time’. If you’re here, then fear not! This is a great place to be – there will always be a lot of work to do, but at least you’re not in the final mindset…
  • ‘Finishing on time is literally impossible’ – This is where you don’t want to end up (obviously). If you put tasks off for too long, or underestimate how long things will take, or just don’t realize that your release date is approaching, one day you’ll wake up in this mindset. You’ll realize that, no matter how hard you work, there’s simply too much work left to do, and you’ll curse your former self for not working harder. Again, please don’t let yourself get here!

The first thing you’ll notice about these mindsets is that none of them really seem great! There’s no ‘everything is on track – lookin’ good!’ The first one kind of feels like that, but it’s usually just a trap. There’s a period of time, I think it’s usually like 6-8 months, beyond which it’s hard to see how a schedule will play out. You can end up in the first mindset, even if you’re incredibly far behind, just because it’s hard for us to instinctively schedule that time.

Checklist

It’s okay – the only thing left to do is everything!

But, either way, it’s okay! Nobody gets into indie game development for the relaxing schedule and numerous spa days – we expect to be behind the 8-ball. The reason I bring this up is so that I can describe where Frank and I are in the process. And you know what?

We’re behind the 8-ball. We have a lot of work to do. In particular, in the past month, we’ve moved from the first mindset to the second. When we had more than 6-8 months left, it felt like we had all the time in the world. Now that we’ve just crossed the border into the 6-8 month mark, it’s starting to hit us – there’s a lot of work ahead of us. Do we have enough time? Can we get everything done?

These are the thoughts going through our heads now. And there are questions that naturally follow – can we still make it? What do we have to do now? What’s next?

 

What’s Next?

planning

This is what planning feels like in indie game development

When you find that you’ve fallen behind in development, you have to correct your process somehow. In my experience, you have three major choices:

  • Delay the release – There’s not enough time to do everything. The fix? Just take more time! This approach is fine (especially when your fans are expecting high quality), as long as your fans are somewhat understanding, you’re not racing against anything (like a competitor, or your own funds), and you haven’t already delayed the release by a lot.
  • Reduce the scope – There’s too much stuff to do in that time. The fix? Just do less stuff! This basically means that you’ll make fewer levels, add fewer features, and maybe decrease the quality that you expect from your game. This is useful, but it can be dangerous – just make sure that the game you end up with is still good enough to be worth it!
  • Buckle down – This one is last, but it’s usually the first one we try. We can’t change the release date – we made a promise to our fans! We can’t reduce the scope – we will not sacrifice our game! Sometimes in life, you simply have to work harder. Before you realized you were behind schedule, it was easy to durdle about, not really getting the important things done. Once you know you’re behind schedule, sometimes all it takes is a mental shift to get more done.

These are the three biggest options you have. Choosing what you need to do at any given point is an entirely subjective task, in that it depends on the stage of development, the type of game, the personal lives of the team members, the average annual wind speed, etc. Basically, I can’t tell you what to do here – if you’re already working 50 hour weeks, maybe you simply can’t afford to work harder. If nobody knows what your planned release date was, and there’s no market pressure, maybe you can just move it back a couple of months. Just choose what’s right for you, and don’t be afraid to re-asses that choice as time passes.

The important part is to actually make a choice. If you realize that you’re not going to finish your game on time, you need to do something. The math isn’t lying, and the longer it takes to make a change, the worse off you’ll be. Recognize that there’s a problem, and do something about it.

Right now, Frank and I are behind, and we’ve decided that we’re going to buckle down. We’re going to work harder and get more done. In another week, we’ll asses our progress and take a look at the road ahead. If we’re still behind, then maybe we’ll resort to reducing the scope or delaying the release. Hopefully we don’t have to, but it’s important to be flexible and honest with yourself.

This post, of course, does not get into the minutiae of how this planning process relates to Where Shadows Slumber, but I hope it was either helpful for your own planning process, or at least entertaining. Until next time, may you examine your own progress, and I hope that you always find yourself ahead.

 

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

If you have any questions or comments about our project planning process (or anything else), 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.

Object Pooling

Posted on by

Alright, it’s finally getting a little bit warmer around here as spring comes and goes, so let’s celebrate by jumping into the pool! That’s right, today we’re going to be talking about an ever-important pattern in game development, the concept of Object Pooling. Object Pooling is a design pattern which involves creating a set of objects – a ‘pool’ – and reusing those objects, rather than creating/destroying objects throughout a game.

pool

Object Pooling involves recycling objects

This is a very important concept in game development, and it’s the first topic we’ve reached that is almost entirely associated with the optimization of a game. For mobile game developers, resources are limited, so it’s important that we don’t waste anything. Object pooling helps us save resources, and is less of a mechanic, and more of a general design pattern. We used it in Where Shadows Slumber, but it isn’t even one of the more defining features of the game. However, it’s still an incredibly important concept.

So, without further ado, let’s dive in!

 

Why do we need Object Pooling?

Unity is a pretty cool system, and it gives you some pretty cool toys to play with. Two powerful toys it gives you are Instantiate() and Destroy(), which allow you to create a new instance of a GameObject, and to get rid of an instance of a GameObject, respectively. I assume that other game engines provide similar functions. If you’ve played around with some simple stuff in Unity, you might have seen how useful these functions can be.

The problem with Instantiate() and Destroy() comes when we try to use them a lot. You see, every time you call Instantiate(), Unity goes into your memory, finds a chunk of memory big enough to store the new object, and allocates it. Conversely, every time you call Destroy(), Unity finds that object in memory, clears it out, and marks that memory as ‘available’. This whole process is aided by the use of a garbage collector, which runs occasionally, making sure that deleted things were actually deleted.

Those of you familiar with computer science may see where I’m going with this. Basically, this isn’t great. Calling Instantiate() or Destroy() every once in a while is fine. But when you call them all the time, Unity starts to slow down. Memory allocations and deallocations are somewhat expensive, meaning the garbage collector will be running a lot, sucking valuable power away from your game! Every time the garbage collector runs, your game might lag a tiny bit. This is doubly true for environments where resources are limited (say, on a mobile device).

So, our clever brain gets to work. ‘Hmm’, it says, ‘if calling these functions is bad, let’s just not call them!’ Brilliant, brain, as usual! Surprisingly, in this case, the first idea that pops into our head is actually pretty good – we just won’t use Instantiate() or Destroy(). Problem solved!

The only remaining question is how to maintain the functionality we had before. We were, for example, using a gun, and every time we fired, we would instantiate a bullet. Every time the bullet hit something, we would destroy it. How can we get that same functionality without using Instantiate() or Destroy()?

 

Object Pooling

The answer to the above questions is, obviously, to use object pooling. The concept is pretty simple – rather than creating a new bullet every time we fire our gun, and then destroying every bullet individually, why don’t we just reuse the bullets? They all look the same, so no one will know the difference!

NonVsPooling

Object pooling in a space shooter (image credit: raywenderlich.com)

This is the idea behind object pooling. Rather than creating and destroying a bunch of bullets every frame, which can get expensive, we simply create a bunch of bullets at the beginning of the game, and reuse them. We store all of the bullets in a ‘pool’ – they’re all deactivated and unmoving, so they have no effect on the game. Then, every time we fire the gun, we grab a bullet from the pool, change its position and velocity so it looks like it’s coming from the gun, and enable it. The bullet flies through the air, and then strikes a wall, or moves off of the screen. At this point, we simply disable the bullet and return it to the pool to be used again!

If this seems a little weird, think of it like extras in a TV show or movie. In the first scene, we need a crowd, so we hire a bunch of actors to be people in the crowd. The next scene is in a different city, but still needs a crowd. Do we fire all of the extras we already hired, and then spend more time hiring different extras? Well, nobody was really paying too much attention to the extras in the first scene – let’s just use them again for the second scene! This is pretty common in TV and movies, and there’s no reason we can’t do the same thing here.

“I gave a very memorable performance as the nurse, and now, suddenly, I’m the waitress? That’s gonna confuse my fans!”
– Phoebe Buffay, Friends

Using object pooling, we can avoid the need for our expensive allocation/deallocation functions (other than at the beginning/end of a level, where slowness is more acceptable) by reusing all sorts of objects. There is a tradeoff here – using an object pool means that, whenever we need a bullet (or any object), we have to be sure that there will be one in the pool. This means that we actually need to store more copies of the object than we ever expect to use. While object pooling makes it easier for the CPU to keep up with what we’re doing, it uses up more memory.

This is called the space-time tradeoff, and it’s pretty common in computer science. The idea is that, in order to optimize for time (make your code run as fast as possible), it generally uses up more space (in the form of RAM). In this case, time refers to time spent in the CPU – saving time means less lag, which makes for a better game. In general, on mobile platforms at least, saving time it more important, so this is a tradeoff we’re happy to make by using object pooling.

 

Where Shadows Slumber

So, how did we use object pooling in Where Shadows Slumber? We don’t have any bullets, so what else can object pooling be used for?

Honestly, object pooling wasn’t incredibly important to the core game – all of our levels are pre-made and we don’t have any projectiles or anything else flying around. Where we did use object pooling was in ‘special effect land’. Every time the main character takes a step, a small sound plays, and in some levels you can see a puff of sand behind him. These are what we have taken to calling footfalls, and they’re one of the main things we used object pooling for.

Footfall

This group of particles is a footfall, and was pulled from a pool rather than instantiated!

In fact, sometimes you may have used object pooling without even realizing it! You see, one of the primary uses for object pooling is within particle systems. A particle system may emit a burst of hundreds of particles at once. Imagine trying to instantiate that many object in the same frame – your game would lag for sure! However, if the particle system uses object pooling, it will simply enable all of those objects, and your game will keep running without a hitch. This allows you to get high-quality particle effects without having to worry too much about the impact on performance.

Hopefully this quick conceptual intro to object pooling helps you out, and saves you many CPU cycles! I should mention that I got an image from this blog post on object pooling, which coincidentally is a very good resource if you want to get a good look at an implementation of object pooling.

 

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

If you have any questions or comments about object pooling (or anything else), 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.

Where Shadows Slumber: Working On A Small Team

Posted on by

Editor’s Note: The post was almost titled ‘Working with Frank Suxxxxxx’, but I decided against it (mostly because it’s not true).

So, you want to be a game developer, do you? You want to be the voice behind the games that so molded your childhood? You want to create an experience for generations ahead to enjoy?

Well, the best way to do that is probably to get a job at-

What’s that? Oh, you want to be in charge of the game development. You don’t want to work on a game, you want to create a game. You don’t want to help someone else make their game – you want to make your own game, in your own voice.

In that case, it looks like you want to become an indie game developer. You get to design your own games the way you want to, which is a thrilling concept. However, it’s not all fun and games and I-don’t-have-a-real-boss, and you should probably know exactly what you’re getting into.

MNCvsStartup

Choices, choices…

Now, I’ve never worked at a professional game development studio, so I can’t give you an entirely clear picture of what you’re missing out on there. I do have some experience with different-sized companies though – my last job was at one of the biggest banks in the world, my current company employs no more than seven people, and I, of course, am on the two-person Where Shadows Slumber team. So, hopefully I can give you a good overview of the differences between these types of jobs and companies, so that you know what you’re signing up for.

There are a lot of differences between small teams and large teams, and there are a lot of similarities. I’m going to go over some of the things that are better about each. These lists won’t be absolutely complete, but I hope I can sketch out a rough image of what life looks like at these different jobs.

Also, real quick, I just want to mention that if I say something bad about working on a small team, I am not necessarily referring to Frank, or anyone at my current job. I’ve been on a lot of small teams over the years, and these are just my general observations, not passive-aggressive pain points meant to make my colleagues feel bitter.

 

The Bigger, the Better

BigFactory

Cubicles, as far as the eye can see!

For the most part, when I tell someone working in technology that I worked for a large bank, I get a negative response, or maybe some sympathy. It seems that it’s not viewed as the ideal technological job. While bureaucracy isn’t exactly my thing, I will say that I did enjoy my time there, for a number of reasons:

  • Responsibility – The thing I liked most about working at a big company was a lack of responsibility. Maybe that’s my 16 year-old slacker self talking, but there’s something really satisfying about not having to worry about the future of the company. Had a bad quarter? As long as I still have a job, I don’t really care! There’s a tough decision to be made? Glad I don’t have to decide! While this isn’t the best way to be thinking about the company that’s providing your livelihood, it is a somewhat calming thought.
  • Funding – I suppose this one is the most obvious reason why a big company might do well. There’s a lot of cash money floating around in the company, so any project the company decides to pursue will be well-funded. Along with this comes a lower chance of failure. Since you already have funding, and you already have a name people recognize, most of your projects will be much more likely to turn a profit. They say that 90% of startups fail very quickly, making startup jobs very volatile. Getting a job at a large company, however, might end up lasting far longer than you even want it to!
  • Specialization – When I worked at the bank, I was on the identity management and access control team. If someone had a question about SSO, security, trading, or anything else, they wouldn’t come to me. I only had to worry about identity management and access control concerns. You end up specializing in a certain area, and that area is your only concern, so you can really learn a lot about it.
  • No Personality Clashes – This is one you don’t really consider that much, but it can be a biggie. Working in close proximity with the same people day after day will probably happen wherever you end up. However, that situation gets a lot more interesting when you have to continuously make difficult decisions with those people. If you disagree, how will you resolve it? There’s no ‘boss’ you can go and ask – you have to work it out. This doesn’t sound too bad, but that’s only because we don’t really notice other people’s personalities until we’re already in the crucible with them. Maybe your partner is incredibly stubborn, and you can’t convince her to change her mind about something. Maybe he’s really arrogant, and he’ll never even consider that your idea might be better than his. Whatever the situation, you need to be able to resolve it. (again, this doesn’t refer to anyone in particular).
    This situation, however, is less likely to occur at a large company. If you disagree with a colleague, you can ask your boss, or quote company procedure, or ‘escalate’ the issue to their boss. In the majority of cases, you’ll only have to work with that person a handful of days out of the year anyways!

 

Less Is More

booth

Just one booth?

As good a case as I made for big companies, working on a small team has also been really awesome. Here are some of the reasons:

  • Decision Making – The first and most important benefit of working at a small company (or, in particular, your own company), is being involved in the decision-making process. When you’re one of the only five people making decisions about your product, you have a lot more say in the outcome. People take your opinion seriously, and you can actually make a difference in the product. This, I imagine, is the biggest reason that people like to work at smaller companies – if I want to make a game that’s really mine in some sense, then the bigger an impact I have on that game, the better.
  • Creative Freedom – This is another biggie, and it’s very similar to the above. I don’t want my boss to tell me that the Ring of Blood item should be red – I want to make that decision myself – maybe I want it to be green! That might not be a great idea, but at least it’s my decision.
  • Pride – When you make something awesome, you have a lot of pride in it. When you’re one of the main reasons that a project is completed, you feel a lot more pride in it than if you only helped out a little. Saying ‘look at my awesome game’ feels a lot better than ‘look at my company’s awesome game’.
  • Learning – When you’re working on a large team, you might end up being a ‘guy’. You might be the ‘shader guy’, or the ‘pathfinding guy’, or whatever. However, when you’re working on a small team, you have to be all of the ‘guy’s. For Where Shadows Slumber, if there’s anything that counts as a programming task, I’m the one responsible for it. That means I have to be an expert on everything. This can be viewed as a bad thing (and I even listed it as a benefit of working at a big company), but I prefer to think of it as a learning opportunity – I know a lot more about shaders now than I would have if I had a ‘shader guy’ to take care of it for me.
  • Working with Friends – Yes, I listed this as a startup-con before, but there’s still something to be said for working with your friends. While it can lead to some messy situations, it can also lead to some brilliant teamwork and a very fun working environment. You just have to make sure you know how to deal with each other before you start working together.

 

The Dream Team

So, what is the ideal team to work on? In particular, what is the ideal team for you to work on? What’s your dream team? Unfortunately, I can’t answer that question. What I can do is tell you about my experience with small teams, and what I’ve learned from it.

17159203_1817437325174646_6524966612565150056_o

This is it. This is the dream team.

Striking out on your own is an exciting prospect. Thinking forward to a future where you’re publishing a game and making enough money to not die is awesome, and knowing that you get to make any and all decisions about that game, making it truly yours, is inspiring. You’ll sit down at a booth to show off your game, someone will ask you how big your team is, and you’ll get to smugly reply ‘it’s just us’. You don’t answer to anyone, and you’re the only one who gets to change your game.

This is also an exhausting experience. Continuing to work hard on your game, knowing the chances of failure, can be very discouraging. Working on the same project every single day, seeing the glacial progress, and still believing that you’re going to ‘make it’ is sometimes impossible. Arguing endlessly with your team members and looking forward at another year of difficult decisions, knowing you still have to work with them every day, is a near-insurmountable mental and emotional hurdle. Not to mention the pressure to succeed, especially if you’ve decided that this will be your only occupation. It’s a task that not everyone is cut out for.

The option I went for ended up being a blend of both. I worked at a big company as my actual job, and worked on Where Shadows Slumber as a side project. This allowed me the freedom to create my own game in my own voice, without having the stress and pressure of living on an indie game development salary. This is an option I would recommend, although I will say that it can be more difficult than either of the alternatives, since you end up doing more day-to-day work, but your game takes even longer to complete.

 

I can’t tell you exactly what kind of team you should be trying to work on, or if indie game development is the career for you. No matter what I say, if you’re meant to be an indie game developer, you will be. All I ask is that you know what you’re getting into before you take the plunge.

 

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

Hopefully this gives you some insight into the world of small teams, and I didn’t scare you off too much. If you have any questions or comments about working on a small team (or anything else), 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.