


Get the latest Education e-news
  • Scope: Maintaining Focus

    - Levon Demurchyan

  • Counterpunch

    Situation I: You're not guilty, it just fell.

    Now, the initial scope planning was done to the best of your knowledge, it's a bar you've set. Hence, you have to hold it there, and not let it fall. Just the moment you start the development, all hell breaks loose. You start to deviate from the plan, add something to the roadmap, lose focus, etc. Well, we have to defend the scope.

    Step I: Just don't do it.

    You add new features along the way mostly, because:

    1. You feel this will contribute to the overall game, or is cool.

    2. You feel like this will not impact the schedule, you can fit it in.

    3. You feel like the game is boring, or misses a feature, and you need to adapt.

    The first one is the most common one, and it happens to all of us. What we need to understand is that even a single line of code, or a simple shader, or a little part of the map, or a little feature has cost. And, you've already allocated a timeframe, a budget to do all the rest, now you're trying to smuggle a little feature in. You have to understand that you're bound by time and by resources. And it's just math. You can't fit 7liters into a 4-liter canister. It's extremely simple, but it is what it is. And, it might be simple, but it's by far not easy. If you do understand all of this, the only way you can let a small, tiny feature smuggle in, is by being off-guard.

    What I did with my team is, obviously, defined what our game is not about, and what we are not going to do. We wrote it down, and we all adhered to it. But, how do we cope with scope creep on a daily basis? Controlling the creative storm is one solution I was able to implement: whenever we had a new idea (and we had a lot, constantly, just like you do) we wrote it down and delayed the decision to a moment where we weren't so emotional about them. And it worked as a charm. The general abstraction is: I try to create a lot of bureaucracy around these decisions so that I can filter the brilliant ideas from momentary, exciting ones.


    - I saw a movie yesterday and I know our game needs this new feature. <...> explanation... <...>, argumentation... <...>, how it is just THE idea that will make the game exciting..., So, what do you guys think?

    - Okay, that's an awesome idea, but let's talk about it next week at a meeting and decide what's gonna happen with that.

    So, what's so important about this? We never say no, we just say, there's this law, that we all agreed to follow, and if this idea passes the filter, we will do it.

    "You are not your idea, and if you identify too closely with your ideas, you will take offense when they are challenged." - Ed Catmull, Creativity, Inc.

    What happens at this meeting, which is called Scope Adjustment Meeting is we have a list of some ideas and changes to the scope, that we have to talk about and try to test them with every tool we have at our disposal. If this idea survives the test and is justified, we do add it. But that happens extremely rarely, as most of the ideas seem awesome, and if they're actually awesome, they seem fitting, and if they really fit, they seem executable in the timeframe we have. If the idea is actually extremely awesome, fits there and is creative*, we do work an hour a day more, but:

    1. We do it extremely rare

    2. We do it responsibly

      1. We calculate the actual efforts that we have to put in, both time, brain, and cash.

      2. We calculate most of the dependencies. (If not, we scrap it)

      3. We calculate the risk of what happens if this goes terribly wrong. (If it's too dangerous we don't put the project in jeopardy)

      4. We don't add features that need more than 4 hours of planning and never do add features that have more than 5% deviation from the estimated delivery time frame.

      5. We ask a lot of design questions, we attack the idea as hard as we can.

      6. We do it only when we have already done that before.

    3. IMPORTANT: We present the idea to the stakeholders, and try very hard to explain why it's a good idea and what tests it went through.

    Now, I want you to understand that these are not just placeholder filters so that you can smuggle any idea in whenever you see fit. This means these filters have to be so harsh, that only 1% of the ideas you have fit there, maybe. Let's do the numbers, there's a lot of ideas coming in, but you only review them once every 2 weeks, and they only have 1% of chance of passing. And, speaking realistically, they (the ideas) actually disappear just before the meeting, because at that point, we have already passed the "creative bliss" state, where we see everything in purple glasses.

    *Creativity is not about having exciting ideas, it's about giving non-obvious, effective solutions to a complex problem. It's important to understand this difference in order to evade the common pitfalls.

    Another lesson I've learned is that if the game you're making is boring, one of these is, probably, true:

    1. You didn't prototype it before production.

    2. You prototyped it but didn't notice that your core features, game loop, game mechanics, and other core design elements aren't good enough and you tried to cover that up with secondary mechanics. Still didn't test it after this assumption.

    3. Tested the mess you've made, and thought that the sole reason for it being boring is VFX, 3D assets, UI, Audio, etc.

    4. It's just you who thinks it's boring, and not the target audience.

    (2) & (3) are very widespread; Adding secondary mechanics and content to a malfunctioning core is something everybody tries to do. That's because you don't want to part with an idea, even though your implementation or the interpretation isn't sufficient enough to make that idea compelling and engaging. Or, in some cases, the idea itself isn't aligned with engagement and is boring. That's when you have to say goodbye or reiterate until the core works, but never cover it up with flashy special effects and emotional epic scores. One of the worst parts of this is that the more you cover it up by building on top of a weak foundation the less visible are the ill elements you have to take care of.

    Situation II: New Year New me

    Market changes affect our work immensely. Sometimes, projects are canceled altogether, because they aren't relevant anymore. And sometimes, we have a short period of time to change the fate of the project by steering it away from certain doom. This also includes budget shortcomings, such as lack of resources to finish the project in the planned timeframes.

    This is when we find ourselves in front of a dilemma: cancel it, or cut it? So, what can we do to get the most out of such situations?

    I believe that every single bit of the project that is not one of the core features, can, potentially, be cut. Regarding the content, just enough content to showcase the features and create a meaningful experience is up to you to define, and it heavily depends on the product; If you're making an adventure, that's one thing, if you're making a MOBA, that's another. As I've said in the previous episode, there are mechanics-heavy games, content-heavy games, and a little bit of both, so it's up to you to define how much content do you need at a minimum.

    We've been making a VR action shooter game with an endless mode, and our core content was:

    1. 1x level

    2. A couple of core systems

    3. 3 heroes

    4. No multiplayer

    5. 4 enemy classes

    But it wasn't the initial plan. The initial plan was to have 12 heroes, 3-5 modes, a lot of systems, cross-play between different platforms, 4 sets of 4 enemy classes, 5 levels. We gradually cut our scope to be able to hit the goal, but we didn't cut it to a degree, where we wouldn't be able to call it a game, to enjoy the core premise, and to present a competitive, meaningful product to the target audience. But it wasn't enough, we had to re-use some content by adding some cosmetic differences, we had to be smarter with what we do ourselves, and what needs to be delegated to preserve precious time. I can't go into details, but there are a lot of things you can do to optimize the workload. 2 things I recommend reading to understand the abstraction: WinRAR technology & Pareto method.

    In the next episode, we'll explore what are the last resort solutions you can apply to a project that is on fire, and I'll share some of the things we did with our projects.


comments powered by Disqus