Scope Creep: is this generally because base design isn't fun?

I'm wondering what the general relationship is between games and scope creep.

My own project definitely had a good amount of it. Perhaps even a huge amount of it. Most of my scope creep was the result of trying to put something bare bones together, deciding that something important was missing (game not fun yet) then deciding to add more tools to work with.

I'm wondering if this is representative of scope creep in general with games. Is it usually the result of looking at a vertical slice and thinking "oh man, this just isn't any fun..."?

I'll happily admit that my process was a total mess from the start, and that the way I iterated was borderline insanity. But I have to wonder if when you hear about games that died of scope creep in development, if it's just because the vertical slices weren't working, and the response was to try to add more stuff.

 

I think there are three main sources of scope creep. Adding more stuff to try to fix the fun is definitely one of them.

The second is adding more stuff because the backer heard that it's the hot new thing, such as multiplayer support, or Xbox avatar integration, or VR headset support.

The third mainly affects new game designers, and really new artists in any discipline. It's the feeling that you have to put all of your ideas into your first game. You might be bursting with ideas, or you might feel like your game has to do it all to prove yourself. But your first game is not your life's work. Your life's work is your life's work -- that is, the cumulative portfolio of all your games and projects. (And of course that's just your game design life. I hear there's more to life than games. ) New writers run into the same problem. They sit down to write the Great American Novel, and they're overwhelmed because they feel like they have to out-Hemingway Hemingway, out-Melville Melville, and out-Oates Oates, all in the same debut work.

 

I would say this is mostly just the nature of gameplay loops. If it starts getting boring, then pour in more content. Retool a level, throw in new obstacles, throw in new enemy types, and if you're really desperate, add to and change some player mechanics.

 

Is that a bad thing? Is it often the road to failure?

Is adding scope sometimes exactly what's called for?

Let's not argue about game play loops. I don't think you understand that "game play loops" are just a very basic, fundamental tools for understanding and analyzing games. They're not a "philosophy of game design" they're an analytical framework. And a really useful one for understanding how the different parts of a game relate in an objective fashion!

 

Even if they are an analytical tool, they are still a way people perceive game design (that would be why they are an analysis tool in the first place). Either way it doesn't change the fact that if the gameplay becomes boring, it's probably because the player has run out of content and explored all of the mechanical depth.

 

Okay lets take for example the game brutal legend. Now it had a lot of systems - you had the RTS battle system, the car system, the fighting system and more. Now none of these were very good or that fun to play and if there was only one of these systems the game would have been completely unplayable. But because it was spread out I found it quite fun -- in a good bad movie kind of way.

 

Since game experiences are subjective, one person might consider an extra feature to be a fun hybrid, while someone else might see it as plastering over an existing broken feature. Do you try to improve the mechanical depth of the original feature, or hope that the interplay of the new feature and original feature creates a new, more fun mechanic? I think this is why fast prototype iteration is so important to finding the fun, and to paring down scope as much as expanding it.

 

To me, if you are adding something to tighten your game mechanic, make it easier to use, tighter controls etc then that's technically scope creep but in a good way. If it's adding extra mechanics, features then to me that's scope creep. Why you needed, or felt you needed, the scope creep may be that you wanted to add each new whizz bang thing you found you could do or it could be that the original design was flawed in scoping what was needed to be fun.

 

Sometimes management screws it up (marketing/branding features added). Other times developers listen to a vocal minority, and ruin their game for the majority (multiplayer feature becomes anti-casual).

 

Picking a balance between MVP and over scoping the project is certainly a challenge.

 

Prototyping is a weird bag. My experience with prototyping hasn't proved that valuable. It's great for zeroing in on some smaller details, or as a rough sanity check, but a lot of time the game needs to be viewed as a whole. I think that at some point, the line between rapidly iterating the actual game is probably more feasible. You need to test how a bunch of the pieces all work together in context.

I just spent the last couple weeks working on revising my class system (for the hundredth time). It's important that these classes play well relative to each other and have contrasting points from one another. Prototyping isn't super useful here, since in order for the prototype to be valid, you need to essentially build out all the different classes and abilities in order to actually try them out. How various abilities feel also really depends on stuff like the animations, particle effects, etc.

My scope ended up creeping in this process. Originally I wanted to have 3 classes, all of them being somewhat similar at core (melee based) with skills that were generally single target. I ended up scope creeping to 5.

In the end I scope creeped in considerable more, including adding a secondary targeting system for potion based grenades with AoE damage. I felt this was needed to help offer more variety and more choice. I also scope creeped the character statistics, since I felt that I needed more tools to differentiate the abilities from each other. This change also meant another revision to UI in order to better present the additional information.

Were these absolutely needed? I'm not sure. Is the game better for it? I sure friggin hope so.

At the end of the day, I didn't think what I had originally was fun enough. So I increased the scope to try to address what I thought were the problems. Although most people probably have a much more structured approach to these things, I can't help but think this kind of process is one that others also go through frequently.

Is this subject one of those cases where, if the process produces a successful result, we call it iteration but when it produces a less successful result, we call it scope creep?

 

Its worth noting that scope creep is just as present in all other kinds of software dev, its not a special problem for games.

 

This, but one step further. Scope creep is endemic in almost all forms of human endeavour. Looking at the more general picture may help.

In general ideas (read scope) are always easier to generate then implementation. Just about every industry has more things they want to do then resources and people to do it.

Sunk cost is also another trap. If you've got 90% of the way to a particular scope item, adding the extra 10% doesn't seem like a big deal. Especially compared to the cost of starting over and doing that 10%. It will always be cheaper to add one new mechanic to an existing project then to start a new project for the new mechanic.

All of the succesful projects I've seen have had scope freezes pretty early in the project. And a manager strong enough to shut down scope changes.

Some practical techniques to squash scope creep.

• Use a stage gate process. Have formal reviews between stages. This makes it clear to everyone when you are in concept, design, implementation and support phases.
• Use product deviation notices requiring paper work and approval to ensure everyone is aware of the cost and schedule impacts of late scope changes. The paper work also makes people think twice before throwing in more scope.
• Have a phase II project. Every project should have a second phase attached. Dump everything that is good to do, but out of scope, into the second phase. Once the first phase is implemented you can implement or scrap phase two as desired.

 

I had a lot of very different experiences. Most of the best software I've produced was generally the product of rapid iteration with user feedback/changes going into each iteration.

It almost always ended up with stuff that users tended to actually be happy with, even in environments where the users weren't accustomed to that.

 

I kinda see creep more as scope limiting and compare it to the stock market.

It is easy to buy a stock (this is creating new scope items). It is hard to know when to SELL a stock. This is akin to the moment you say "This game's design is done, no more stuff to be added" - that's the hardest part of the design process Just like knowing when to sell a stock it is part experience, part science, and part just gut instinct.

 

At the core all games have a basic game framework, so of course you'll always have to add to it to make it a complete product.

It's when the scope is above and beyond the original scope by a huge amount. e.g If a linear design equates to boring so you push out the boat to the point it becomes and open world experience, therefore increasing work effort massively just to add "fun" and gameplay time then there's something seriously wrong with said design.

 

Not Scope Creep:

Player core loop needs more to make it fun, rewarding, or just cool. Maybe a fun powerup or collecting things just makes the game better.

Score Creep:

In a Jump n' Gun game a talent system, inventory and chat get added. You might get away with the talent system if it allows players to do something really interesting. The others are probably silly.


A really common thing that non-engineer people do is spend 3 seconds looking at something before asking for all sorts of features and changes. It was a Q3 Arena style shooter, now it is a PVP MMO with questing and a loot grind.
Classic scope creep.

 

What is your conception of a prototype? I think of it as a small, microcosm of the whole, that allows testing core behaviors. Sometimes, it's a vertical slice. Sometimes, it's a horizontal end-to-end test. Sometimes, just one mechanic.

@ironbellystudios captured the idea that EXPERIENCE makes the difference. Experience with failure, with success, and with scope. And, prototyping helps you with all of that. I'm struggling to think of even one game where prototyping wouldn't have been a good idea. Even games as diversely complex as Civilization, Grand Theft Auto, and Hearthstone.

Gigi

 

I'm not saying that prototyping isn't useful. I guess my point is that at some point, in order to prototype something in enough detail to really get a solid feel, you might as while just implement it.

Perhaps this kind of issue is why so many successful games have crazy extended Alpha/Beta periods. I believe that Diablo 3 iterated on it's class and skill progression systems well into beta.

I think there's some point where systems can't be quickly prototyped in isolation. Where that point is may vary, greatly, with experience, but I think that once you've got a number of subsystems that are all working together to produce something like "satisfying progression" prototyping starts to break down, or the time required to build the prototype that can answer a questions like "are your classes well defined, clearly communicated, and valid/useful in various combinations?" starts becoming more cumbersome than simply implementing the 'real' version and trying it out.

 

I always considered feature creep to be what happens after

1. you have established what the minimum viable product is.

2. Your planned content already satisfies your goals for the game.

If the game isn't fun yet, it isn't really a viable product.

But maybe feature creep isn't always a terrible thing.

I keep thinking of the scanner in metroid prime- it wasn't a core feature of the game, but it allowed an avenue to inject narrative and lore to enrich the world they were trying to create. Maybe it wasn't necessary, but it was useful as a difference in kind from the main gameplay, and to give the player something to do during calm moments rather than just blitz through areas. I can see a feature creep addition turning into that.

Though as a later addition, I imagine such a feature would be very expensive and time consuming to add. Perhaps that's what makes it creep.

 

I think that feature creep, iteration, or whatever you call it is sort of a hindsight thing. If it goes well and is successful then it's the more positive "iterative process', if it ends up being a disaster it's "scope creep".

 

Another factor might be just how much of a disaster it turns out to be. Like if you spend a couple hours fiddling with a new feature and it turns out bad, that feels like it's to be expected, it's a normal part of early dev. But if you sink a month adding a feature and propping it up by inventing tie-ins to the main gameplay and it turns out to be bad, well you really could have done something to prevent that earlier.

 

It all depends. Scope creep is very common in IT work. It is probably one of the biggest factors contributing to projects going over budget and failing to meet deadlines. However I've always thought it comes back to poor project management.

Anyway... I think it is very normal to want more. And when you are directly in control of the project wearing the hats of manager and developer it is way too easy to think "this is not too bad but it would really be cool if this was in it too". I don't really see this kind of thing as scope creep. I see it as design. In fact I coined my own term for it that may already be a "thing" but who cares really.... I call it developmental design. This is the process of identifying things that should be removed or things that should be added and only occurs during the development and play-testing.

You can also just call it prototyping but since the focus there is generally on the tiniest least amount of something necessary to proof an idea I didn't think it accurately described this phenomenon. Developmental Design does. It means you may continually be adding more and more and more and more because the design itself is increasing. You are actually designing the game while developing it. Scope creep I see as something where you have a goal identified and you budgeted hours and money to achieve that. Then maybe halfway through the requirements change, the scope increases yet the deadline and money remain the same. This is bad.

Prototyping is what I do when I am asked to make an enhancement at work. Basically I design it first (roughly on paper) identifying all that I can. Then I throw out a huge estimated number (I mean huge) for time required to implement. And I suggest taking the time to do some prototyping to more accurately identify the true scope. So then I am asked to do that (because they really want the number to come down) and so I proceed to do the bare minimum and identify along the way the "better" ways of doing things and estimate the work required for that and the benefits of doing it. But for actual development I am always thinking what is the minimum I can do to meet the goal? Ultimately I end up with a finished "thing" that can be tested and along with it a list of known limitations and a list of ways to get around those limitations with their associated cost and a list of enhancements (things that might be nice to have) and their associated cost. That is all for work though.

I do that a tiny bit at home but mainly I enjoy the creative freedom and use developmental design to explore things and let the design evolve as a result. Maybe this is what happens with you

 

Dead on Gar. Dead on. I think this is also why developers tend to think of 'scope creep' as a kind of doom march to failure.

I think this is a huge point. I think this really gets to the heart of the discussion.

Learning how to 'do something to prevent lost time earlier' or how to leverage different methods to achieve that is a process. I think this process is very similar to the same process in other creative endeavors. It may also be one of the best measures of raw experience. What's that old saying?

Something like: “An expert is someone who knows some of the worst mistakes that can be made in his subject, and how to avoid them.”

So I guess the question is - what tools or techniques can we use to avoid mistakes with a minimum amount of time - and how do we identify when each is most appropriate.

I gave my experience on the 'bounds' of prototyping: the more integrated something is with other systems, the worse it's candidacy for prototyping (or the more a prototype starts to become 'the project'). I sort of think of a prototype like a Unit test, which differs somewhat from an Integration test.

For me, the tricky part is more about the integration testing, which I think is where 'iterative design' starts to be a better approach.

I donno though. @Gigiwoo's definition of a prototype is much broader than mine. I sort of doubt that an 'end to end' prototype can actually answer questions about how the game plays as a whole without ... becoming the finished product.

Anyone willing to share some actual experiences or examples?