"Scope: Choose A Target! Focus! Shoot!"

Introduction

A comprehensive guide on how to manage scope, not to scope creep, and finish your game... probably.

What is Scope, why is it important?

The Scope is a term widely used throughout the video game development community to refer to the sum of all features and content chosen to be developed at a given time. It’s the focus of your creative and development endeavors at any given time.

Managing Scope in game development projects is extremely important because what happens with Scope during the development process either makes your game or breaks it. Too many developers, broadly speaking, suffer greatly because they poorly manage the Scope and end up in a very sticky situation leading to severe execution problems, a decrease of morale, anxiety, loss of product vision, and other problems.

Frankly speaking, I categorize the problems in the following way:

Both sets of problems are very dangerous, but I tend to believe that the latter is more important and I’ll tell you why. Throughout my career, I’ve had many instances of scope mismanagement, but the most severe consequences I had came from the dynamic scope mismanagement. To clarify, the scope was chosen correctly, but I let it out of my control and it started to shift and swell, ultimately making the nominal choice of scope irrelevant. Also, don’t take my word on it, I have a quote from a book widely regarded in many creative industries as the Bible of creative team management. The book is called: "Creativity, Inc." by Ed Catmull.

Let’s suppose you’ve chosen the scope incorrectly, and started the development. In most circumstances, you can always shift it towards the correct direction, or in this case, the correct scale, and come out as a victor. There are circumstances where you can’t*, for example, if you shot a trailer where you show a given primary game element - you can’t get rid of it without substantially giving explanations. You can always be a naughty dog, but you better know the cost. Let’s just assume you can always shift. And you have to.

Some of the sticky situations or problems you can end up with, in case you mismanage Scope:

And, the question of the day is...

How do we (possibly) avoid these problems?

In the following articles (coming very soon), I'm going to try to convey three points that are very helpful and cover my vision of the sufficient framework to battle scope mismanagement.

"Choose the target": It is important to cast yourself and/or your team into a bordered region that you don't have to cross by any means*. There are a lot of points in this phase that we're going to cover to help you understand some of the mechanisms producers and/or game makers generally use for this matter. Setting yourselves on the correct rails right off the bat saves you a lot of time and saves you from the necessity to steer the "ship" in the right direction.

"Focus": It is more important in my opinion not to get off the rails. There are a lot of temptations along the way, that most certainly will lead you and/or your team to perish. But there are a couple of concepts and methods that you can and have to use to counter those temptations and presumably land in the projected point in the projected amounts of time.

"Shoot": There are cases where for whatever reasons you weren't able to put yourselves or keep yourselves on the correct rails. This is a very difficult situation, but I regard this as an important point to provide you with some gambit moves, where you might be able to save some portion(s) of the project.

Part I: Choose a Target!

So, choosing the scope for a game is a delicate matter. What does it mean to choose? Like in a shooter game, you first choose the target in your direct view. You see targets in the field, behind the car, on top of a building, etc. Most importantly, there are also tanks, helicopters, heavy targets frankly speaking. What is the algorithm by which we pick a target? It depends on where you are, what weapons do you have under your disposal, what’s your health, how big is your team, and many other parameters. You probably don’t shoot a tank in the wheel with a handgun. As primitive as it may seem, this is what nearly every developer does during the first steps in their career, of course metaphorically speaking. We always want to make the best game ever. We just pick a wrong target blatantly ignoring the fact there is no opportunity to take it down in current circumstances with the current tools we possess.  

Before we go to the next part, there is an important point I want to convey. Yes, you probably have an idea about what did you choose, but do you know what you did not choose? Choice involves inevitable sacrifice, otherwise, the choice has never been made.

We've always valued grounded, defined docs when we started working on our latest project, and this exactly applies what I've said just above in a real-world scenario.

There are many criteria game developers use to assess if their target is chosen correctly. I am not going to go deep into this topic from every perspective. Let’s just assume you already know what genre, what kind of a game you need to build as a result of market research, and comparative analysis of your capabilities. Because we speak about Scope from project management and game design perspective, I am going to cover only these topics in this section, as I have enough knowledge and vision on the subject matter.

Your budget mostly consists of three (3) resources:

Brain Resource is the capital ability to deliver on a given feature. How much knowledge does the team have on the subject to develop the required feature list? In other words, it’s the core competency of you and/or your team. It becomes a problem when you don’t have it because then you also can’t calculate how much time you need to deliver on the feature. This is the budget unit developers always neglect by just assuming that they will be able to learn along the way. And this is, most probably the deadliest mistake in game development. I want to be extremely clear: It’s not forbidden to chase the unknown, even more, it’s mandatory for growth. But what fraction of your project is unknown? Is this learning curve too steep? That is the real question. 

Time is a very important resource as it is irreplaceable. Time is continuously working against us, and we have to be very selective with what we do with it. The time budget is the amount of time that you have to develop, market, and release the game. As I’ve said it’s irreplaceable so you ought to be extremely careful with this resource. This is why you have to measure the target game and ask the question: How much time will it possibly consume? This is the time requirement or level of effort. Will I and/or my team pull it off in the given timeframe? To answer this question you have to include minor time-consuming actions and tasks such as lunchtime, rest time, etc. These seem so unimportant and irrelevant from the first glance but will backfire immensely if miscalculated.

Finances or Cash is another important resource that sometimes helps you decrease the time requirement (in some cases) and/or add brain resources to your team, for instance. Every project demands labor to be completed, but Time and Finance can both buy you Brain Resource, in most cases. If you don’t have an artist on the team, you can always hire one, or if you need a weapons pack for your game you can always buy one already made, or hire a freelancer to make it for you. If your team hasn’t developed a given feature, they can try and learn. There are specialized third-party studios that help your studio in those areas you have no, or next to none competencies. Large studios often partner with other studios that are more competent in certain processes. It lets them focus on the core parts of the process that demands their attention. This also happens when certain business opportunities arise and you need a helping hand.

Another important point to consider while adjusting the nominal scope is the sum of the core features and the content. This (and a lot more) is the cost that you have to subtract from your budget. Having a negative value in this is a huge red light. You should always adhere to this method, as it is one of the easiest and one of the most practical ways to understand if you're in the possible region. I'll go deeper into this in a separate article.

Core Features are the features that, when removed or changed affect the whole game drastically. Removing one or more core features so much changes the game that it is not the same game anymore. There are also peripheral, “secondary” features and are also defined by the game designer(s), as they need to be balanced with the core mechanics.

Try thinking about these:

Now, these:

And these:

So, which of these are the features, that in case they are removed leave the game broken? Maybe a little bit different? There are cases where we can argue days long whether a feature is a core feature, or if it is secondary, but when you have to choose - you have to let go.

Another way of looking at this is when people are asked what would they do if they knew that they have only 1 day left to live. In most cases, they choose a couple of things that are of utmost importance. This is exactly what we want to achieve here.

Content is obvious I think, that is how much… content your game has. It’s not the mechanics or features, it’s how big of a field a particular game provides you with to learn, play with, and master its mechanics.

There are many approaches to game development and choosing what is the right thing to include in the MVP version of your game is up to you. It all comes down to what do you want to make. Some games are content-heavy, others have minimal content, the same comes down to the core features, or features, generally speaking. There are also games in the marketplace that have many features and a lot of content. Why is it important to make an MVP version first? Because in 99% of cases you don't know what do you want to make, and I mean it from a projected/final perspective. And I don't say it lightly, game development is so complex that we rarely have a realistic projection of what it's going to be in the end, and most importantly is it going to be entertaining?

It is extremely important to measure capacity before going deeper into the process. This obviously comes with experience, as you can’t measure how long it is going to take to implement a weapon, or an AI character in case you have never done it. Yes, you might be able to relatively calculate how long it takes to make Call of Duty and extrapolate that onto your game, but do you actually consider all the factors? This is why every experienced developer in the industry would highly recommend you start small. That’s generally because you start blind. You need more empirical data to understand how long it takes to make a game or its element.

As I’ve said, you don’t want to make a bad game, most probably. But there should be a balance to how much you crank into your schedule. You don’t want your team to work more than 8 hours a day, believe me. This is not because nobody’s going to work more, probably the contrary happens. If your team shares your vision and is inspired by the sheer fantasy of what they can achieve if they work more hours they will voluntarily stay late. But there are many instances where this is proven to have just the opposite effect. Working longer hours is normal, but it can’t be regular. You can’t be serious when you think your team can do 3 years' worth of labor in 6 months. That’s going to have severe consequences on team morale and is unethical in my opinion, even considering it might be possible to do in 6 months. You can crank up the stress to hit a deadline, but be responsible when doing that, you can always break the meter and reverting the consequences might not be realistic.

Pixar was able to deliver on the deadline, but at what cost? We never read that in the success stories, but behind most of the masterpieces, there are always colossal sacrifices.

That's all for now, please stay tuned for the next 2 episodes coming very soon.