Scope: A Lesson in Game Design

By [03.11.08]

 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.

 The Multi-Faceted Designer
To be able to properly scope a project, you must understand all the other departments. Nobody expects you to be the best at any of the other positions (if you were, I assure you they'd have you doing that no matter how good a designer you are), but you should have a good enough grasp of the other disciplines to roughly understand the labor cost of anything you'll be designing. Simply including the words "navigate through fully realistic waves" or "perfect human fidelity" in a design document can sink a project.

If you're unsure of the cost of any particular piece of your design, ask. It's as simple as that. People will be honest, even when they're trying to avoid work. I've found that when someone gives me an unreasonable time estimate on something they don't want to do, usually it will really take them that long to do it.

Cost-Benefit Analysis
Designing within scope is sort of like playing a game. You have limited resources and you have to choose carefully where to apply them. Once you know what everyone wants to do and how long it will to take to get things done, it's time to focus on what you're really trying to accomplish.

Define the heart of the game's experience. Make a list of bullet points that, if you delivered only those but they were all phenomenal, the project would be a resounding success. As you are designing the features, try to assess how they relate to your bullet points. This coupled with your understanding of team resources should give you a good guide for what is achievable.

Designing for a Client
Often we don't have the liberty of designing whatever we want. Often we have the constraints of a franchise, a corporate structure, or a client to deal with. In these situations, it becomes even more important to understand what qualifies as a win for them.

Don't let them get into specifics about the development. Instead, find out what they want to convey to the end user. Hopefully this will give you enough room to design a project that meets their needs, has an appropriate scope, and is something the team wants to work on.

Scoping the Details
Scoping, as a method, can also be applied to individual mechanics or granular pieces of a game's design. When designing individual game elements, always keep in mind what those elements are trying to accomplish. It's easy to start looking for answers without really understanding the question.

There's a famous story about a team who was making a racing game. The client says, "We don't think the cars are shiny enough," so the team goes back and develops a really nice system for curved reflective surfaces. Everyone on the team loves it, and they present it to the client. The client says, "It's just not right." The team quietly starts tearing its hair out until someone asks the client, "What do you feel shinier cars would be adding to the game?" The client promptly says, "It would make the cars seem faster!"

The problem wasn't with the aesthetics at all. No one stopped to ask how shiny cars would affect the core experience they were aiming for until they diverted massive resources toward the problem. By that point, it was too late. The project ended up running over time and over budget.

Cheaper and Better?
Making things simpler can often improve gameplay. Always be on the lookout for things that make the project easier on your team and more fun to play.

It may sound impossible, but it comes up all the time. Let's take Assassin's Creed. I've read review after review decrying the distance the player has to travel between the main cities. If Ubisoft had just put in a simple menu that allowed you to move between the cities when you got to the city boundaries, they would have saved the game a huge amount of geometry and would have improved the gameplay.

Know which features are important to your project before you start to design or build it. No project makes it through with all its originally intended features intact. When it comes time to cut, know what to fight for. When unexpected difficulties arise around building some aspect of the game, you must be able to assess if that part of the game just became too expensive; be willing to let it go.

Design with execution in mind.

Plenty of people have grand visions or genius wild ideas, but, unless they understand the ramifications of those ideas and can design around them, those visions will never be realized. For yourself and your team, be realistic. Dream big, then fit those dreams into the reality of making a game. That's the real skill of a designer.

James Portnow is a game designer at Activision. Email him at jportnow(at)

Return to the web version of this article
Copyright © UBM TechWeb