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. 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.
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:
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:
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.
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.
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:
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.
What if there are too many values? Again, start with a focused analysis of this specific parameter.
Licenses owned by the publisher
Target platform
Age group
"Action" dimension
"Adventure" dimension
"Thinking" dimension
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)
3rd Stage - Filtering Ideas and Defining Preferences
As we have seen, a concept is defined by a set of parameters and the values chosen for each of them. For instance, the solution for concept number one is as follows:
The solution for concept number one.
Combining all values, we find 2560 possible configurations:
2X4X5X2X2X4X4
Rest assured, we are not going to examine every one of them. We have a method narrowing the field down to just a few.
Narrowing the Scope
The method of reducing the number possible configurations for a given parameter with values is to define exclusions and preferences.
The exclusions
Exclusions are pairs of values which are incompatible and therefore of no interest. Here are a few examples for our racing game concept:
The first pair of values are ruled out since a realistic underwater racing game makes little sense. The pair "resource management" and "racing" is also eliminated since a consumer who buys a racing game expects a credible universe. Resource management is usually a far cry from reality. The entire value, titled track racing, is also ruled out because this marketing segment is already saturated with titles. In all, 45 exclusions are made in this example.
The preferences
Preferences are values and pairs of values that appear particularly promising for various reasons: internal know how, lack of competition, control of a suitable license, etc. Here are a few preferences for our racing game:
In the example above, a simulation is ruled out because priority is given to an "arcade" type of gameplay. More importance is placed on "adventure" dimension parameters, which in our opinion will produce a rare mix of genres. On the other hand, we will stick with a classical type of vehicle, namely land vehicles. In all, I have identified 50 preferences here.
The Table of Retained Ideas
We now have all the elements necessary to draft a table containing all of our hypotheses. It is best to use dedicated software such as Morphol, published by French software house Heurisco. Once I have all the exclusions and preferences in place, the software works out the remaining hypotheses. Thanks to software filtering, we are down from 2560 combinations to about sixty. Hypotheses will appear as code. For example, solution 2.3.2.2.1.1.3 corresponds to arcade, navigation, team management, very important ("adventure" dimension), race track, ground (vehicle), and car racing respectively.
4th Stage - Analyzing Hypotheses According to Priorities
Once the valid hypotheses are identified, they are classified in order to isolate the best possible concept.
Selecting Criteria and Assigning Weights
To determine the interest of a particular concept, we need to establish a set of criteria. Let us select the following:
Set of criteria
The list of such criteria is established by the whole team. You are free to use as many criteria as you feel necessary, but experience shows that the maximum should be around ten. This creative thinking is particularly beneficial because it motivates the group to consider what is truly important for the game and for the studio. In the next stage, weights are attributed to each criterion:
Rating Hypotheses According to Selected Criteria
We must now rate each solution on a scale of 1 to 5 for each individual criterion. For instance, for solution 2.3.2.2.1.1.3:
Reconciling Opposite Views
There is one problem, however, when rating hypotheses. How can the studio come to terms with contradicting opinions — for instance, from management and players? The solution is to assign more than one weight to each criterion. In our example, we identify two groups that judge the interest of a concept from different angles: management and players. Management will be preoccupied with figures, while players will be less concerned with budget issues. A new table is necessary to take both groups into account:
Analyzing the New Ranking
The new table is now much more informative. As we can see, the ranking of hypotheses varies significantly depending on which point of view is chosen.
Ultimately, how do we retain the lowest amount of possible variants? Priority is to be given to those hypotheses that will satisfy both groups.
Here is an example of a configuration that creates a game concept that merges two genres: racing and adventure:
We can also identify a few hypotheses that did very well in one ranking but poorly in the other.
Here for instance, the following criteria translate into a rally racing game with a storyline, a concept that did not score that high.
Finally, don't throw away ideas that are extremely original, and therefore hardly imaginable by the competition. Keep one or two hypotheses that rated average, but are dear to the heart of someone in the team, as possible concepts.
Applications and Conclusions
In the example used for this conference, I define the general mechanisms of a game project. Once the best hypotheses are selected, designers can take over and focus on concrete goals rather than just "grope in the dark". However, there is more than one application to this method. The following are a few examples.
Evaluating a Game Project According to the Publisher's Expectations
In this situation, the purpose is to seduce the publisher above all else. Suppose the studio is out pitching a game concept to a major publisher who owns a number of licenses. We can use the following parameters:
Licenses owned by the publisher
Target platform
Age group
"Action" dimension
"Adventure" dimension
"Thinking" dimension
Multiplayer dimension
Once we have isolated our game hypotheses by means of exclusions and preferences, we can pick the best ones by applying the selection criteria that matter most to the publisher and the development studio.
Development cost
Use of in-house know-how
Deadline
Originality
Designing an Original Game Mechanism
Another application for this method is in researching a particular aspect of a game. In the following example, we will investigate a new interface for a strategy or tactical game for the console market. One of the reasons why this game category never caught on with consoles was because consoles lack a mouse. Therefore, the challenge is finding an interface that relies exclusively on the use of a pad.
Parameters:
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)
Conclusion
This method is not a "black box" that takes in data and produces a number of original concepts. What is important is the process it generates. The latter is just as significant as results proper. The use of this method cultivates exchange and encourages dialog. It lets everyone speak their mind and channels everyone's reflections.
In conclusion, our method helps achieve the following goals: 1/ put a large workgroup into creative motion by focusing collective ideas around a few major points; 2/ identify those combinations of features that no-one has previously thought of; and 3/ establish consensus around a result.
Read more about:
FeaturesYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
