Many of us can certainly relate to the situation when the studio is almost done with a new game and it's time to think about the next project. The company management assembles a small team of contributors including programmers, artists, designers, a project manager, and of course the studio executives. A brainstorming session is called together to outline the key features of the upcoming project. Everyone, eager to share ideas at once, eventually turns the meeting into anarchy. This scenario usually happens because everyone has their own agenda and individual priorities. A game designer will fancy an innovative game mechanism, a programmer will push for some technological breakthrough, while managers will look for concepts that can sell to publishers or fit the studio's budget.

Then, everyone has their own pet projects, that one game which is close to their heart that they would just love to develop. Amidst all the enthusiasm, management soon finds it very difficult to take a number of contrasting suggestions and turn them into valid and ideas. An alternative way to work out a project is to limit the number of contributors. A group of two to three people from among company management will focus on a small number of personal ideas, or will concentrate on key imperatives for the studio.

Indeed, this approach will make it easier to define a project, but will the result be any better? Decision makers, whether in a brainstorming session or in a limited committee, face the same problem: too many parameters that must be merged into a single concept. Furthermore, this kind of decision-making process is not truly motivating to the rank-and-file employees, who are forced to go with a project without being consulted.

The method presented in this article is designed to foster creativity and build a consensus. It is by no means a magical formula or turn-key concept, but rather a decision making aid, used to identify better choices. It helps select the best project ideas regardless of the number of parameters involved. This method also makes it easy to establish a consensus around a project, and more importantly, produce equally good results for large as well as small teams.

1st stage: Defining goals and getting organized

Set the boundaries
The method discussed in this article could be used by a workgroup that looking to develop a new project from scratch. However, in most cases studio managers often have a few imperatives already in mind. For the sake of our example, we will assume the management has determined to build a racing game for the new generation of consoles (XBox, PS2 or Game Cube).

The Workgroup
Before going ahead with this article, a few words should be said about the people who make up the team. They must be members of the studio. They should come from a different setting such as computer graphics, programming, etc. The main criterion is that they have a good knowledge of the gaming world. It is equally important to have several people with a manager's vision such as a development director or studio manager.

The group must include a person knowledgeable in this method, who will guide the team's musings into constructive hypotheses. The size of the group is of little importance. The method discussed is designed to consider everyone's ideas, therefore making it applicable even to even large groups.

2nd stage - Identifying parameters and their values

What is a Parameter?
Parameters are the characteristics of a game. For instance, the parameter called "background" can have the following values: contemporary, heroic-fantasy, science fiction, middle ages, etc.

A game project can therefore be defined as a set of parameters, and the values selected for each of them. Choosing parameters and their values is therefore an important step. In the method presented in this article, the first stage is defining such parameters and their associated values. For instance, here are some of the possible parameters that could have been used when creating Alone in the Dark — The New Nightmare:

	Values that are assigned to each parameter. The values describing the game are highlighted.

The Choice of Parameters
In our racing game example, after some decision-making, the group determines to focus on the following parameters:

• Marketing segment
• Type of gameplay
• "Action" dimension
• "Thinking" dimension
• "Adventure" dimension
• Game area
• Vehicles

A few comments are in order, such as:

1. How do we select the parameters? It is a delicate task. It is best to prepare a preliminary list and then submit it not to the workgroup but to the studio management. The latter will usually come up with new ones including parameters specific to the studio. I must remind you that one of the goals of this tool is to build consensus around a single project and that falls in the area of responsibility of upper-level management.
2. You can have as many parameters as you want, but for practical purposes, I recommend to limit it to about 10. If you need to use more, it is always possible to split the work into several sub-systems.
3. The parameters all have to be independent from each other.

The Choice of Values
Once the parameters are selected, proper values must be identified. Let's look at our list of parameters and some of the values.

A few questions will certainly come up:

1. How do we go about a composite value, that is, a value that combines more than one sub-value? For instance, the "vehicles" parameter can assume combined values such as ground-air, ground-air-water, etc. There are two possible hypotheses: with a small number of combinations, a simple enumeration will suffice, and when combinations are numerous, make a preliminary analysis of the parameter in question. The best ideas found here will then serve in the final analysis.
2. What if there are too many values? Again, start with a focused analysis of this specific parameter.
   1. Licenses owned by the publisher
   2. Target platform
   3. Age group
   4. "Action" dimension
   5. "Adventure" dimension
   6. "Thinking" dimension
   7. Multiplayer dimension
   • Development cost
   • Use of in-house know-how
   • Deadline
   • Originality
   • Control usage (planning, action, mixed)
   • Control object (units, goals, resources, construction)
   • Control condition (real time, suspended game)
   • Control method (game window, dedicated control window)
   • Interface representation (2D, 3D)
   • Control menus (contextual, permanent)

     Evaluation criteria:

   • Simplicity (of the interface)
   • Richness (of possible actions)
   • AI requirements (to assist the player)
   • Speed (of use)