Est. reading time:
8 min

Lets tie up some loose ends

The last blog discussed how we took our vision from an “action-brawler” to the more unique and innovative “adventure-party” game. However, some of you may be thinking that one does not simply build an adventure into a party-game, and you are absolutely correct; that would take many more hours to complete. That is why this blog post is about scoping Project Tumble and some creative solutions to stay within that scope.

James Portnow’s article on scoping describes the importance of planning the work demands of a project to accommodate the scale of the vision and strengths of the team. Scoping allows cost-benefit evaluations to most effectively deliver the intended experience within the scopes limitations and avoid running out of time or resources before the vision is manifested.

scope, Devblog 2: How to cope with the scope, Digital Devotion Games

The 3 defining elements the scope must balance – making this image was a low scope task.

scope, Devblog 2: How to cope with the scope, Digital Devotion Games

Written by
Sune Hvidt

Reaching the next deadline

First of all let’s provide a little insight into the product management of our development. Here is how we dissect the scope of Project Tumble to make it more manageable. This makes it easier to spot the dreaded feature creep, where adding more features reduces the overall quality of the game.

Roadmap VertSlice Smaller, Digital Devotion Games

Re-using assets is a good way to stay within scope

Separating the project into chunks by setting milestones is a good start. Each milestone describes when the game reaches a stage of development that opens up new advantages for the game. For example, the vertical slice that we currently build towards is ideal for showcasing our vision to potential investors, funding partners and publishers. To reach our vertical slice by December, we must balance quality of the game with the urgency of reaching this approximate deadline. To get the right balance we estimated that about one hour of gameplay is a good goal.

Next up, Mikkel introduced us to a modified version of Project Increments (PI) to make scoping the individual milestones even easier. For more on PI’s here is a nice GDC talk by Linda Fane from Bungie. Basically, we separate the scope for the next milestone into steps that we call PI’s. Each PI is focused on a specific part of the game experience. At the end of a PI we have a syncing period were we playtest and realign the team so we don’t lose track of our vision. Here are the six PI’s that make up our vertical slice:

PI 1 – The Fundamentals

PI 2 – Build the Adventure

PI 3 – The Theme Park Experience

PI 4 – Memorable Moments

PI 5 – Player Individuality and On-boarding

PI 6 – Utilities

For each PI we estimate how much time we need to reach its goal by determining which features it requires and what stage we should get those features to. We then setup sprints with the predictable tasks and dependencies sorted out. For our first PI we set up 4 sprints over the course of 8 weeks to get the foundation of the game in place.

Accidental feature creeping is easy when viewing the full scope where an extra feature just looks like one more droplet in the glass. However, by working in sprints towards each PI, the scope of each feature suddenly gets a lot more tangible and spotting the looming threat of feature creeping gets easier.

Making more than the sum of the parts

With the production framework laid out we can get back to the problem prompting this blog: How do we manage fitting the adventure within our scope? To fulfill the vision, Project Tumble will need a few things to expand beyond being a collection of minigames. Namely bigger levels with more activities. The trip to our “theme park” shouldn’t be over before players get the chance to be rewarded for their investment and make memorable experiences together.

scope, Devblog 2: How to cope with the scope, Digital Devotion Games

This is where the content is going to be

We solve this issue by utilizing the emergent gameplay inherent in our design, where reusing content can create new interesting situations just by changing the context. For example: We can make the same minigame provide two unique experiences based on where or in what level we place it. We can also present the same type of challenge to players, but give them different tools to complete it to provide more interesting gameplay from the same content.

By making different types of content that can either change how players interact with the world, each other and to what end, we quickly create many unique situations from few pieces of content. Being able to reuse content like this is a tried and tested way of doing game development and is a big part of why we can stay within scope.

Using this strategy we ultimately save time creating content through clever use of level design, leaving time to improve the games fidelity.

Restrictions sets creativity free

Speaking of fidelity, using too much time on creating high quality content is also problematic for our scope. However, scoping down a feature doesn’t mean that we have to sacrifice the quality of that feature. Instead, the magic happens when you rethink how to reach the goal for otherwise high cost features.

A great example for this is the evolution of our hub-world that we originally wanted to be a cul-de-sac where the player characters live. A cul-de-sac, however, gets its charm from its visually distinct houses which unfortunately requires a lot of work to have the right impact. Instead, our artist Nikolai took it upon him to create a mock-up of a hub-world that would fit within the limitations of the scope while still retaining the aesthetic quality we strive for.

scope, Devblog 2: How to cope with the scope, Digital Devotion Games

No adults allowed!

And here is what he came up with over the course of an afternoon using assets that we already had made (and a few from the asset store). When he presented it we were immediately sold, that is definitely how we want our remote, unsupervised “clubhouse” to be. It isn’t a cul-de-sac, but after seeing Nikolai’s concept we definitely believe that the effort required to build a bunch of houses is put to much better use elsewhere.

As is the case with this example, working within the constraints of a scope can actually be good for promoting creative solutions. Many studies have been made on this subject showing that giving yourself restrictions to work within can be worth it. Adequate constraints sparks creativity as necessity is the mother of all invention.

But what about those darn darlings

Sometimes though, a feature is simply just too big to fit the scope. In our case it is one of our original ideas of a visually changing world that players could “paint” with imagination. And a good part of our current demo is build on the basis of that idea.

scope, Devblog 2: How to cope with the scope, Digital Devotion Games

First iteration of a fully changing world

A visually changing world is a cool concept that we hold very dearly, however it only really fits one of our new pillars. Furthermore, testing our early demo showed that just visually changing all assets in the world 1:1 was underwhelming. Thus the feature would not only require multiples of every asset, but also a lot of work to get the feeling right. Realizing these problems could have massive impact on our scope, we did some cost-benefit evaluations. The results: devoting the effort required to implement the feature, would in turn take away from our ability to make the overall gameplay better.

So do we just… declare it a darling and kill it? While we don’t have the full answer yet we have determined that killing the idea of a fully changing world is better than risking the entire project on a sunk-cost fallacy.

However, our cost-benefit analysis did also reveal that certain elements of the feature were great at conveying the games theme and creating impressive moments.

After all, turning a stick you found into a sword is really cool. And a castle raising from a lake can have a lot of impact! Neither of which would require the same massive level of scope as the darling they originated from. And honestly, they might even be better at capturing the imagination we want to convey. By killing our darling we have freed the lifeblood of the intended experience from a sinking ship.

So when you finally get to explore the world of Project Tumble there is a chance that you will have some really cool surprises in store.

scope, Devblog 2: How to cope with the scope, Digital Devotion Games

… and now you know why it probably didn’t cost our entire budget to make 🙂 🙂 😐

Wrapping up

Summarizing our experiences so far, here are some key takeaways and lectures we have learnt:

  • Dissecting your scope makes potential feature creep more noticeable.
  • Reusing content is one of the best ways to stay within scope – so make it easy to reuse content.
  • Consider what intended experience that a feature should bring is and what is actually needed to capture that experience.
  • Kill your darlings with cost-benefit evaluations.

In the end, scoping boils down to estimations and rigorous evaluations to stay on top of the uncertainties. But the methods presented in this blog are applicable for just about any project.

If you found this post interesting and want to see more, you can subscribe to our mailing list here:

See you ’round the block!

Sune, Game Designer

scope, Devblog 2: How to cope with the scope, Digital Devotion Games