Last week, we discussed what game scope is and how to estimate it. As a follow-up, today we’ll be talking about how to reduce the scope of our game into something workable. We will discuss the key feature, Minimum Viable Products, and how applying them turned me into a narrative designer.

Preview

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

How to Reduce the Scope of My Game?

Let’s start with a quick recap of what game scope is. 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 in the game. Then, project scope is the requirements for actually making the product scope: team size, development time, budget, etc. Check out last week’s blog post for more in-depth information.

We used ‘Super Mario Bros’ for the NES as an example. The product scope looks a little 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

So, we have our product scope, with all the bells and whistles we want for the full-fledged version of our game. We’ve established project scope estimation is not viable, it will take too many years to complete. How will we go about reducing the scope of our game? From this point on, we’ll be aiming for a narrow game scope: a product that’s focused on a single key feature. In short, we will trim everything that does not emphasize that key feature. Let’s talk about that.

Identifying the Key Feature

What is our key feature? Let’s look back at our product scope and try to find the heart. Ignore the Content list for now, and focus only on the Features. I assume there are some basic things on there that all games in your genre have: movement, shooting, multiplayer, crafting, farming, score, turn-based, etc. Generally speaking, you want to avoid using those as a key feature. If you have a feature that already stands out in the genre, subverts expectations or flips conventions on their head, or is completely original in its own right, that’s probably a good key feature! From a marketing perspective at least. 

If you don’t have any features like that, we can workshop the expected genre features into something specific. Adjectives come in handy here. For example, just having “movement” as a feature for platformers is not very expressive. What kind of movement is it? Is it fast-paced movement? Is it slow and deliberate? Is it janky physics-based? Do you have wild mode of traversal never seen in any other games? Finding an expressive combination of adjectives for our feature can turn it into a good contender for key feature.

But what’s even more important in my opinion is, what feature would you want to work on? Curiosity and passion are my biggest motivators. If the idea of programming a swarm of millions of characters sounds fun to you, why not take that as our key feature? Why not make the creative solution to a technical problem our key feature? If there’s something you want to learn about, that makes a great contender for a key feature by itself.

Alright, so those are some methods to pick a key feature. It’s important to pick only a single key feature. We’ll use that as our guiding star for the rest of the product scope.

Minimum Viable Product

With our key feature identified, we can get to work at our Minimum Viable Product, or MVP for short. As the name suggests, an MVP is the most trimmed-down version of our game. It is not the perfect version. It is probably not even close to what we imagined our full-fledged game to be like. It is the version of our game with the least amount of Features and Content, while still being functional. This means we need to whittle down our initial product scope into an extremely concise list.

So, let’s take our product scope and highlight our key feature. Then, we remove all features that do not directly depend on or uplift our key feature. If you have to squint to see the connection with the key feature, take it out as well. Be aggressive with pruning! Don’t try to make any excuses to keep features you like, but don’t have a connection. Only keep features that you really believe can enrich the key feature. Personally, my aim is to be left with no more than 3 features in total.

For me, that step can already change the entire shape of the game. Maybe I set out to make a top-down, story-rich RPG with original puzzle mechanics. I highlighted puzzle mechanics as key feature and found that walking around and talking to characters does not uplift the key feature. So now I’m making a puzzle game without RPG elements instead. This can be hard to do because we have to let go of our ideal imagined version now. I promise we’ll get a more streamlined game out of it as a result!

In ‘Super Mario Bros.’ case, I would argue that player movement is the key feature. I’m going to get flak for this, but I would argue that 2 player co-op is completely irrelevant to that. Collectibles definitely uplift the key feature: they set goals for the player to get to through movement. Powerups, however, already fulfill that function and in addition add more interactions that go well with player movement. That feature for sure wins out over coins and lives as collectibles.

Cutting Content

And what about content? Well, by cutting out features you’ve probably made some content redundant already. Let’s cross that off first. Now we’re back to guesswork again. How much content do you need to uplift our key feature? Too little content will get stale and repetitive and won’t bring out the key feature’s full potential. Too much content and it will cease to be minimum and viable. We’re aiming to get the most out of our feature, so you have to carefully select the smallest amount of content to emphasize said feature.

In the case of ‘Super Mario Bros.’, I would say we don’t need a boss in the MVP. For enemies, I think it would be good to have at least one enemy to emphasize each powerup and each player movement. That’s a total of 6. For levels, I think we can apply the same logic. 1 Level to introduce each powerup and movement and then another level that acts as a challenge to the player’s mastery. That’s 7 levels in total. Let’s see what we have now.

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

A bit skinny perhaps, but let’s plug it into the project scope calculation again. 

2 Features * 13 Content * (1 + 0 Unexplored Territory) / 100 = 0.26 years of development time

Seems a lot more viable, but also a lot more minimum. Would that be good enough for a commercial hit? If not, what do we do with the MVP?

What To Do with a Minimum Viable Product?

For some games, the MVP might already represent a streamlined and fun product that people want to play. For others, it might represent a strong foundation that you can expand on. From here, you can try to figure out a healthy product scope between the minimum and fully-fledged versions of our game. Or, we can start building our MVP right away and use it for:

• A pitch to get funding to make the full game.
• Publishing as Early Access to get community feedback and expand gradually.
• Launch as Free-to-Play and make premium future content.
• Iterate on it to get closer to a full-fledged game.

The main goal of an MVP is to figure out the bare minimum you need to emphasize your key feature, but it has other uses as well. I highly recommend finding the product scope for the MVP as soon as possible in your development cycle. What you do with the MVP is ultimately up to you, but at least it will give you a good overview of what your game is about.

Iteration

I mentioned that we could use an MVP to further iterate on our game. As per last week’s formula, Unexplored Territory can easily double (or more) our development time. This is because of all the research and trial and error that comes with trying something you’ve never tried before. Iterating on concepts you have experience with is a surefire way to save on development time. 

This can be done in multiple ways, through per-game iteration or through prototyping. For the first, I always point at Supergiant Games, developers of ‘Bastion’, and, more recently, ‘Hades’. If you go through their catalog you can clearly see that each game shares strong DNA with their previous games while always bringing something new to the table. Since Bastion, each game has shared a similar control scheme and polished real-time action. ‘Transistor’ then came with an innovative system for build customization. ‘Pyre’ came with an interesting take on procedural narrative. ‘Hades’ took all those elements and polished them to a shine. It also introduced Rogue-lite progression, which they will now iterate on in future releases.

It’s always a good idea to build a foundation using your expertise. If you want to tackle ideas you’ve never tackled before, try to mix them with concepts you’re already comfortable with. 

Prototyping

The other way to cut Unexplored Territory is through prototyping. A prototype is jury-rigging a playable game together to test out a concept. It does not have to be polished or free of bugs, as long as you can make it fast. The main goal of a prototype is to answer any questions you cannot answer during the design phase. 

You can use any tool available to you to make a prototype. No art skills? No problem, just find some free assets online. No programming skills? No problem, you can use an existing game of our genre to test the fundamentals, then imagine our own mechanics on top. Minecraft, Roblox, Twine, or plain old pen and paper are all good tools for prototyping.

Spelunky’ and ‘Celeste’, the platformers I mentioned before, are both iterations on prototypes the developers made before. They cut out some of the Unexplored Territory, which made development of the fully-fledged games faster and more focused. So, those are some ways you can reduce the scope of your game. Not only will this drastically reduce development time, but it can also help you make decisions for the future direction of our game.

What is Narrative Scope?

So, I can hear you ask, what does any of this have to do with narrative design? Unless you’re making a visual novel, branching narrative, or other story-driven game, “story” will rarely be our key feature. That in turn, means that our MVP will most likely not use whatever outlandish stories we’ve come up with when imagining our initial game.

But, if you squint at the features that you did keep, you might see a relation form between them. In those relations lie the boundaries in which our story should take place. A narrative scope, if you will. Gameplay features are the means by which the player expresses their part in the story. Providing context for that gameplay is what narrative design is all about. I highly recommend keeping that context inside the boundaries of the narrative scope, at least for our MVP.

Here’s an example. When I make an MVP, I usually end up with something like “resource management” as a key feature. A feature that emphasizes that could be “social mechanics”, like building friendship, leadership, or status. Then I ask myself, how does resource management affect social mechanics? Themes of scarcity, wealth, supply and demand, greed, and envy come to mind. A story starts to form around that. If I have another feature, like “survival”, the story becomes even clearer. How do social structures change when everyone is fighting over resources to survive? 

Then we try to constrain those ideas to our narrative scope, and it ends up looking something like this:

More often than not, when I’m making an MVP, I find that features with strong relations appeal to me the most. Realizing this, I stopped fantasizing about the fully-fledged version of my games and started focusing on key features that tell a story together. I think I was always interested in this aspect but was blinded by all the gameplay and content ideas that come with the conception of a new game project.

Trimming away those ideas using an MVP leaves us with a more streamlined and focused game. Also, constraining the narrative scope to the key feature helps us create a context centered on player expression in the story. Since prioritizing that, I’ve found that narrative design is a more effective method for player engagement than relying purely on gameplay.

Conclusion

Determining our game’s product scope early on and trimming it down to a Minimum Viable Product can help you create an overview of how long our game actually take to create. Don’t be afraid to cut away features and content that don’t fit your key feature. Unexplored Territory in particular is a dangerous thing to mess with, so make sure to prototype and iterate on concepts you’re unfamiliar with before implementation!

A clearly defined scope will also help you make design decisions for a more streamlined product. The same goes for your game’s story, themes and tone. Try to constrain your storytelling to the narrative scope of your MVP’s features.

Hope this helped you define the scope for your project. If it did, and you want to stay up to date for other blog post when they come out, make sure to subscribe to my weekly newsletter here:

TLDR