Scope Creep

Guy A: Let’s make a game about a zombie.
Guy B: Let’s make it simple, no combat.
Guy A: Sounds good.
Guy B: And laser guns.
Guy A: What?
Guy B: And ragdolls, and body dismemberment.
Guy A: But we are so close!
Guy B: You’re dampening my creativity.
Guy A: No, you’re making an impossibly huge vision that–
Guy B: What if we had vehicles?
Guy A: None of this is necessary to complete the original game idea.
Guy B: Wow, okay, so even thinking about new ideas is a bad thing to you. Jesus Christ.
Guy A: I’m just saying, every thing you add makes this take 10x longer for no real benefit.
Guy B: Oh, so you DON’T want to make a good game, then? Is that it?
Guy A: I’m just saying, we should stick to the simple plan and discuss how to implement.
Guy B: I finally realized it. You’re holding me back.
Guy A: Wow, ok?
Guy B: I’m destined for greatness. And by the way, you’ll never get anywhere in the game development world with your attitude.

1 Like

Ha ha. Sounds like Guy A and Guy B don’t make a good team. One actually wants to complete something quickly. The other wants to brainstorm for a possibly unlimited amount. Can’t really get any further apart than that.

Is Guy A you in this case? Of were you being held back? Or completely hypothetical scenario?

I have been both guys. I suspect at some point, we all have. :confused:

It’s funny because as my actual abilities to do things have increased, my patience for endlessly beating around the bush and brainstorming keeps diminishing.

3 Likes

“wouldn’t it be cool if…” = scope creep.

7 Likes

There are a ton of management strategies to deal with scope creep.

A couple of my favourites:

Use a stage gate process. All parties agree on the scope at each gate. Ideas can run rampant before a gate, but once a gate is passed, ideas are over. Each gate narrows down the scope of work.

Have a generation two project. Any ideas that come up that are outside of the scope get pushed into the generation two project. If the first generation succeeds, you can immediately start on the second. If not, then you haven’t lost anything.

7 Likes

I present to you Guy A’:
Why make a zombie game I can just buy one if I want to play one. Let’s make a game with this unsolve, untested mechanic or setting.

  • project work fine for the first 95%, the mechanic is almost solved but there is this small concern that break everything ans you cet stick on it the next two 95%. You can release a janky dumb down version, but prefer not, soured by the lack of purity of the concept. Next project: why make game with fighting in it? The future refused to change …

Reading threads like this make me think people really have absolutely no self control or iota of professionalism going by the hypothetical conversation :stuck_out_tongue: Seems illogical and emotionally driven. I wouldn’t allow such a thing anywhere near my work.

Just do proper project planning and have a clear leader. The leader needs to understand that it’s not his project, his job is to see the project succeeds. So it’s not a good job for everyone.

5 Likes

get rid of Guy B RIGHT NOW!

I know the type very well. These are not good developers. Hell, I wouldn’t let them work in ANY job where they had any kind of freedom… they will feature creep chopping down trees if you don’t restrict “their creativity”.

And given “their creativity” is not producing very creative ideas (none of the ones above is anything else than copying what others have done before), I would say this person is not adding ANYTHING to the project.

Always a matter of perspective… I’d say he is adding a huge amount of work to the project. :wink:

I agree with what you’re saying! :slight_smile:

2 Likes

Never heard the term stage gate but seems similar to the process we use at work (software dev not games). Ideas are collected and documented. They are reviewed quarterly to decide which are immediate “yes let’s do it” (easy low hanging fruit type stuff), which are worth allocating time to investigate scope of work, which are maybe worth considering and which are just thrown out.

The first two become work items going forward. The latter two do not. Although the “maybe worth considering [but not decided today]” items are just kept in the queue to be revisited next quarter. If they sit in there for too many quarters they either have to become an action item of some kind or thrown out.

For my own personal projects I use the second process you described. Ideas are just documented for another game, sequel, a “maybe later if I have time”, etc.

1 Like

I guess it depends on how much of the actual work person B is doing.
If person B is an “Ideas guy”, get rid of him immediately!

In my experience, right after you’re done doing most of the actual work, he’s going to say it was all his idea and he’s the reason it is what it is.

1 Like

Guy B: Let’s make it simple, no combat.

Guy B: And laser guns.
Errm ok guns without combat.

Split Personality A: Lets finish feature A
Split Personality B: Lets start feature B
Split Personality A: Lets fix bug C
Split Personality B: Lets research D

1 Like

Try having this conversation with yourself as a solo developer, lol

6 Likes

I think this is the major reason I prefer working solo…Because although it almost certainly doesn’t seem like it based on my tiny games part of me does continually come up with more and more ideas or wants to iterate on the graphics to “make them better!”, increase the overall scope, etc.

But I listen to that voice then ignore 95% of it so I can actually complete games. Granted I do think I go too extreme on that focus hence loosening up for next project… somewhat.

2 Likes

You need to start by defining your minimum viable product (MVP). What is the smallest, simplest game that you can build to show off your core gameplay mechanic? Build only that to start. Show it to people. Get feedback. Then iterate.

Things like vehicles should not be in the MVP. Depending on the game, it might or might not make sense to have vehicles. But initially, don’t waste time implementing vehicles unless it is literally a game about vehicles.

Both Guy A and Guy B should watch the following video and then discuss how it applies to the MVP for their own project:

https://www.youtube.com/watch?v=UvCri1tqIxQ

2 Likes

Well you could make ben and ed

Now if you had the zombie on a bike that could be hilarious.

1 Like

But not for himself.

1 Like

Yep! That’s why it is always so easy to just give input to other people “you should change this”, “you should add that!” and so forth.

Talking is very easy & very fast compared to actually doing the work. :slight_smile:

Is it combat if you’re one-shotting everything?

1 Like

Too bad I’m the Guy B and I work alone so there is nobody to put some brakes on me. Sigh where is my Girl A? (you can keep Guy A thanks) :smile: