Scope Meaning In Game Design

What's the number one reason projects fail? What's the biggest title killer in the industry?

Scope -- or more accurately, a lack thereof.

What is Scope?
The scope of a project is its breadth and depth. What are you making, and how complex does it have to be to achieve what you want?

Scope is something to be decided, not something to be discovered post-facto. This may seem silly, but many projects roll forward without someone taking a step back and asking, "What does doing this really entail?"

Scope, most simply put, is the understanding of how vision meets execution.

Vision Vs. Execution
The "vision" of the project, in terms of understanding scope, requires detailed foresight about what the game will be: its genre, numbers of hours of gameplay, graphics quality, number of players supported, number of levels, quality of the AI, and other aspects that would be thought out fully in a game design document. I also think of vision as an understanding of the core of the end user experience -- what's fun, and how will the player experience it?

"Execution" relates to the production of the game and implementation of its parts: the number of developers needed, budget, production timeline, class of tools (how powerful, how expensive) to be used in development, and other more hands-on considerations. A game with clear scope matches up the right level of execution for the vision.

Who Controls Scope?
Many people think producers control scope. This is one hundred percent wrong. While producers have veto power, they can't actually enact anything themselves. When the producers on your project start to its control the scope, you're in a fail state.

So who is it that defines the scope of a project? It's the designers. They directly determine what the boundaries of the project are and, if they fail to do it well, they jeopardize the entire project. (Note: This is on the macro level. Everyone must interpret and scope their individual tasks all the time.)

While this examination of scope is intended primarily for designers (it is written by a game designer) it can be applied to any field. Insights from people in other disciplines are eagerly welcomed. I'll happily participate in discussions on the forums.

Designing for the Team
If you know your team going into the project you should design to their strengths. As a designer it's vital that you know the interests and abilities of the people you're working with. When people are working on things they are enthusiastic about and are good at, it's amazing what can get done.

If you haven't worked with all the members of the team before it's fair just to ask them what they're interested in. If you want to be more circumspect, you can ask them to tell you their favorite games. This should give you an idea of what they like (though asking point blank is always better).

Try not to set up anyone's expectations. You may not be able to design a game that's perfect for everyone, and if someone feels like you catered to everyone except him or her, it can create a world of problems.

Often it can be useful to weigh the strengths of the team by department when you are beginning your design. If you've got a killer engineering team but a weak art department, design a game that relies on the programming and runs light on art. If you've got a sound team that's going to knock things out of the park and an art department that's just short of Picasso, you're better off making Geometry Wars than Crysis, if you don't think your engineering staff can handle it.

Be honest with yourself. If the design department is the weakest link, let the rest of the team carry you (reskin something tried and true). If your team is terrible, just keep it really simple, make the project clean and elegant, and you'll all get out of there fine.