If you just started out making games, you might have heard the following advice before: “Make your game smaller.” People new to the field don’t always have a clear idea of how much work goes into making certain content or features. This is called a game’s scope: the size, workload, and viability of your project. Today we’ll be talking about what game scope is, how to estimate the scope of your game and a little tool we made to help you out with it!

TLDR: If you’re here for the Game Scope Calculator, click here instead.

Preview

• 10 Minute Read
• Beginners/Intermediates
• Useful for game makers starting a new project

What Is the Scope of Games?

Allow me to make a brief tangent before we get into it. I’m currently going through a metamorphosis of sorts. For almost a decade, I was a ‘Technical Artist’. That’s a job position in the game industry that can be loosely described as someone who helps artists work faster and easier. This can be done by making visual effects, improving the game’s performance, or optimizing workflow with tools. That last part was of particular importance to me. The artists at the company I worked for had a huge amount of work to do and no time to do it. Saving time was vital.

When you optimize workflow, you look at every step of the game development process to see what can be removed or improved. I found that the most effective way to save time is to know exactly what you need to make. Some of that comes with experience, some with effective planning, but most of that comes from defining our game’s scope beforehand.  So, what is scope? Simply put, it’s how much effort will go into making our game! “Effort”, however, is a bit too vague to measure. For now, let’s take a look at the two different types of scope: product and project scope.

Product Scope

Product scope can be described as a breakdown of everything in our game from a player’s perspective. What can a player do in our game? How much of it is there to do? When defining product scope, we aim to make a comprehensive list of all the features and content we want in there. For this blog post I use the word Feature to roughly mean “gameplay thing the player can do”, like crafting or racing. I use the word Content to measure the amount of assets in the game, like levels, items or characters.

For the classic ‘Super Mario Bros’ on NES, for example, It would look something like this:

• Features
  • Player Movement: Jump, Dash, Climb
  • Powerups: Big, Fireball, Invincibility
  • Collectibles: Coins & Lives
  • 2 Player Co-op
• Content
  • 15 Enemies
  • 1 Boss
  • 32 Levels

Seems reasonable enough! We’re not focusing on details yet, just a rough outline will do for now. Parts of the product scope are often copied directly to market the game as well: “Look at all this stuff our game has!” To get a better idea of a game’s product scope you can check out its store page for example.

Project Scope

Project scope, on the other hand, is everything we need to actually create the stuff outlined in our product scope. Again we will make an outline, but this time we include things like team size and rough estimates of development time. I’ll use Super Mario Bros as an example again, but the actual information is made up, so don’t quote me on this!

• Project
  • Team Size: 5
  • 2 Programmers, 2 Designers, 1 Artist
• Programming: 18 months
  • Player Movement: 1 month
  • Powerups: 2 months
  • Collectibles: 2 month
  • 2 Player Co-op: 3 months
  • Enemies: 10 months
• Design: 16 months
  • Player Movement: 2 months
  • 15 Enemies: 4 months
  • 1 Boss: 1 months
  • 32 Levels:  9 months
• Art: 14 months
  • 2 Player Characters: 2 months
  • 15 Enemies: 5 months
  • 1 Boss: 1 month
  • Level Setpieces: 6 months

This reveals a bit more about the time and work that goes into creating a video game. For a single person, this would take about 4 years to complete! So, in short, scope is a rough outline of your game and how much time it takes to create it. But how did I land on these numbers? Are they even reliable?

How Do I Estimate the Project Scope?

I’ve started game projects too big to be viable for over a decade now. Part of that is grossly underestimating how long certain features or content would take me. Especially things I had not done before were hard to estimate. I call that Unexplored Territory, and it adds an incredible amount of research time and trial and error to your project. Because of that, I’ve recently tried to come up with a little formula to help me estimate project scope based on product scope. It goes a little something like this:

(Features * Content * (Unexplored Territory + 1) ) / 100 = development years

Let’s break that down real quick. You add all the Features from your product scope together. You tally all the individual Content pieces together. For Unexplored Territory, I put in the amount of Features that I’ve never worked on before. I also count Features I’ve only tried tutorials for as Unexplored Territory. There’s a constant plus 1 to Unexplored Territory, otherwise, you can develop a game in exactly 0 years if there are no new concepts to tackle and that strikes me as inaccurate 😉 Then, you multiply all that together and get a result somewhere in the hundreds. You divide the result by 100 and get an estimate of years of development, assuming full-time work. Essentially, this is a formula to calculate volume, so I like to visualize the project scope as a cuboid, like this:

Let’s take our Super Mario Bros example and apply our little formula. For this little thought experiment, I’m making myself the lead designer of the project. Yes, you heard it here first. I made Mario. A slight problem though, I’ve never designed 2 player co-op for a platformer game before. Oh well… here goes nothing!

• Player Movement + Powerups + Collectibles + Co-op = 4 Features
• 15 Enemies + 1 Boss + 32 Levels = 48 Content
• Co-op = 1 Unexplored Territory
• 4 * 56 * (1 + 1) = 384
• 448 / 100 = ~3.84

So, by myself, I can probably make a platformer game the scale of Super Mario Bros. in about 4 years. Want to try this out for your own project? Check out the game scope estimation calculator tool! Wait a minute, that sounds like a lot, right? Making platformers should be pretty easy to do nowadays! We then come to the second thing that makes it easy to underestimate scope.

Hidden Costs

So, is that formula actually accurate? Well, I wouldn’t call it an exact science, but let me explain why I think it would take me 4 years to make something akin to Super Mario Bros. 

The observant among you might already have noticed something missing in my product scope. Where is the audio? Does my game not have music and sound effects? What about marketing? Surely I would need to spend some time promoting my game? What about business decisions, research, community, and playtesting? The list goes on. All these things are necessary, and take time!

The above formula assumes you only put in the prominent features and content of your game, as you would describe it to your players. It then spits out a very rough estimate of how much work it might be for a single person. You can divide the result by the size of your team to get an actual timeline for development. After that, your mileage might vary quite a lot. For reference, both ‘Spelunky’ and ‘Celeste’, two more recent platformer games of similar product scope as Super Mario Bros., took 2 years to make. Two people made Spelunky, while Celeste’s team was about five people in size.

Because of its wide margin of error, I don’t recommend using this project scope estimate for anything serious like making a budget or development roadmap. It is useful for answering the following questions, however. Is your game scope viable or is it too big?

Is My Game Too Big?

So there we have it, the big question. Is the scope of your game too big to be viable? Probably, yes! Even experienced game makers tend to underestimate scope. Taking on a project with a 2-year or longer development cycle is risky, especially if you’re self-funded. As of writing, game publishers are also playing it safe and prefer not to take big financial risks. So unless you are a dragon with a hoard of gold to fund a dream team, I will assume your initial estimated development time is going to be too long to be viable. But no worries, together we’ll figure out why it’s so big.

Creative Influx

When you brainstorm at the start of a project, a flow of ideas for features and content will spill out. Each of those ideas will seem as good as the next, and quickly your product scope will start to balloon into a massive list. “We got to have a complex crafting system! What about multiplayer? We need at LEAST as many playable classes as our competitors!” As game makers, we have a tendency to dream up a complete version of our game. That’s not necessarily a bad thing! Let inspiration strike you like lightning, and get all the ideas out of your system. In fact, I suggest you note down all the features and content you eventually want in your product scope.

But, if you calculate the project scope based on this massive version of your game, you’ll be chipping away at it until you’re old and grey. Luckily, games these days still have room to grow after they launch. In fact, they’re expected to grow! So even if your initial vision of your game is not viable, you can trim out non-essential features and leave them for later. I recommend focusing on a single key feature and removing any feature that does not emphasize that feature. We’ll talk more about that in next week’s blog post. Whatever ideas we cut out, we can always keep them on the docket for post-launch content.

Feature Creep

Another dangerous pitfall for game development is feature creep. This usually happens during development rather than before. Feature creep is gradually adding new features or content to the game that will eventually lead to missed deadlines and broken schedules. Expanding on your initial design here and there is a part of the creative process, of course, so that should be expected. Feature creep, however, happens when you think every new idea is worthy of implementation.

An unfortunate victim of feature creep is ‘Star Citizen’. The game has been in development for over a decade and has managed to raise and waste more than half a billion dollars. It’s been widely criticized for overpromising, underdelivering, and the addition of undesirable features. It will likely have to add more hostile business practices just to keep development running, without ever delivering a fully-fledged game.

To illustrate how easy feature creep is: I dealt with it even when writing this blog post. Initially, this blog post’s subject was about estimating game scope AND reducing game scope into something viable. The whole thing bloated into a 30+ minute read, even before I had the idea of including the calculator tool. Thanks to readers’ feedback, I opted to cut it into 2 parts, with a more focused scope for each. To combat feature creep, it is important to keep estimating scope even during production.

Conclusion

When people give you the advice “make your game smaller”, it’s usually out of concern for its viability. It’s a shame to see interesting games in development slowly fizzle out through feature creep or underestimating development time. Especially inexperienced game makers can be starry-eyed with ambition, but making games is always more work than you expect.

To make a realistic and workable game, you should define a simple but appealing product scope. Then you can decide if the project scope is worth your time and energy. To ensure a smooth development process, keep estimating the scope for new features as well. I hope this blog post and our calculator tool will help you get a better overview of your game’s scope.

Thanks for reading! If you want to read more about how to reduce the size of your game, go read this follow-up article! If you want to get notified when more of these posts drop, you can subscribe to my weekly email newsletter:

TLDR