Scaling your game design scope.

“Correctly balancing scope and polish is one of the biggest challenges of the dev cycle, IMO. At the end of the day, we all try to make creative, ambitious games — and balancing a constrained resource/time pool against hopes and dreams of greatness is a hard problem to solve, whether you fail to cut enough to start with, or add so much later on that you can’t polish it. So I thought I’d put the question out there: what are good strategies or exercises you/your team have used to manage scope while preserving core project integrity?”



A good friend of mine posed this question recently, and I started to write up an answer and it started to get out of hand, so I thought I’d put something up here instead.

This is a _really_ good question since I’ve seen many teams struggle with this. The initial scope was too great, how do you scale it without compromising on the initial design?

My answers involve the concept of pre-production. Part of the point of pre-production is to understand *what* it is you are making. During pre-production that initial desire / idea will and should change based on the results of your prototypes and design work, and will change further when you hit the Vertical Slice.

One of the crucial things to understand here is to grasp what your constraints actually are at this point. What is your budget? What is your time scale? Take those, then reduce by 10% to give yourself some slop, then TATTO THEM ON YOUR FOREHEAD. Every decision you make has to fit within those constraints and you have to know they fit. If there is any ambiguity, then that has to be chased down and nailed to the wall. Sure, some of what you cast will be wrong, but not attempting to nail down any of it firmly is the fastest way to budget and time overruns. You’ll probably have that happen anyway, but at least you haven’t made it significantly worse and when it does happen you’ll at least have a fair portion of constructed game to show to make the point that you should be given the overrun, rather than having waspy nothingness – if you go into a meeting to ask for more time / money and say “And right here will be…” you are done.

So what is pre-production? Well, that’s a post (in fact a book) by itself. Pre-production is the generation of the full design of what you want to make. Lots of prototypes, lots of design work, lots of visual imagery, lots of working out what the actual scale is. Pre-pro should result in the knowledge of what you intend to make in terms of scale and so on. Rather than starting with outlandish ideas and attempting to force ways to make it happen, it’s an organic process that will whittle away that which is un-necessary to the core concepts, and it’s also a process that will actually test that those core concepts can actually be made.

Pre-pro for a new feature set / genre is always harder since you don’t know what it is that will work or not up front. If you have a team with a lack of experience in an already solved area (like streaming a large world for example) then it’s a question of iterating on a prototype till you get it working since you already know it’s possible.

For something new that’s harder – when do you stop iterating on a feature that doesn’t work initially? What if it’s a core feature? What do you do then?

It’s worth pointing out that Pre-Production is designed to prove out the design ideas and it’s entirely possible that the basic root design is unfeasible, or not makeable by the team you currently have. Whilst not many teams want to think that, it IS a possibility – you may come out of pre-pro with no game to make, or a game so cut down from the initial idea that no one has much enthusiasm to make it.

Ok, dire warnings aside, how do you do it? I mean how do you approach what you build and the brainstorming you do for features? How do you filter stuff?

The first thing to do is work out what the core design is for what you want to make – down to a one or two line definition – and then measure every idea by that. If your core design idea is GTA in the Star Wars Universe, then that’s great – every one has a mental image of what that is. It’s harder for a new genre game, but the effort needs to be made.

Then, every idea that is proposed is measured against that design. Someone comes up with a great idea for a face sculpture system. OK, measure that against the basic idea – how does that help the root of what we want to make? It doesn’t. OK, it’s out. Viola, instant scope scaling.

One nice idea is to actually have two completely different approaches to each task, one that is a more proven fall back but that isn’t as sexy, so if the ‘new’ approach doesn’t work you at least have a contingency to fall back on should you need to.

But what about idea’s that *do* compliment the design lines but are going to prove unwieldy, only we don’t know that yet? Well, job one is to actually break down everything by system – ie all that can be isolated as a separate task.

All need to be listed and prioritized according to the root game design. In our example, if the team has never built a world streaming game before then the streaming system would be a high priority to determine the risk factor for. Anything new that the team has never done before goes to the top of the list, prioritized against the root need of the game design at that point.

Then you go away and either build prototypes against those systems, or do design work or whatever is called for. Basically you prove as much as you can in isolation so you a) get an idea for the problems involved and b) get an idea of how it might be implemented. The prototype doesn’t have to be a complete technical solution to whatever the problem is, but should be enough that a complete and thorough understanding of what is required to implement in game comes out of it.

For game systems (ie the ‘fun’ producing parts) those need to be iterated on until they *are* fun. A basic “Yeah, we can make a camera” prototype is not sufficient in this case – the team must know that what they’ve got is fun since that generates interest and the desire to work harder on anything.

So how do you cut that which isn’t working? Well, if it’s root design requirement you either bite the bullet and continue iterating, or you come back and substantially change the initial design. If something root to the design doesn’t work then there aren’t that many other choices.

Then comes your vertical slice, where you try and put all this disparate prototypes together and see what results. And again, some stuff will end up going away, or being scaled back. You may intend to build 15 levels for a game then find that in actually building one complete one you understand there is no chance of doing that within the constraints you have.

You may find one system overwrites another, or takes too much time to actually use in the constraints of a 30fps game. Whatever – this is what a vertical slice is for, to test and highlight these issues.

Then comes production. How do you order this? Well, everything that is cool but extraneous to the main design goes at the end of the schedule, so it can be cut easily if other things overrun. That’s just common sense.

Dependencies should be worked out with that which is core and root to the game design coming first and everything else after. Constant tracking and metrics of what is done and what is not needs to flow during production so producers can know at what stage the game development is at, so they know if they should be cutting levels or features even.

I can go on, but you get the idea. Sometimes you cannot cut scope without affecting the design because the initial scope wasn’t feasible within the constraints in the first place. Hopefully though they won’t be and pre-pro will give you the info you need to know how to how to cut it (or find ways to accomplish it) up front.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>