Sponsored By

The Right Decision at the Right Time: Selecting the Right Features for a New Game Project

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.

Pascal Luban, Blogger

September 26, 2001

18 Min Read

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:

luban_01.jpg

 


 

luban_02.jpg

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.

luban_03.jpg

 


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)

  3. 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:

    luban_04.jpg 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:

    luban_05.jpg

    Examples for a 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:

    luban_06.jpg

    References for the 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:

    luban_07.jpg

    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:

    luban_08.jpg

    Rating 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:

    luban_09.jpg

    Rating Hypotheses According to Selected Criteria

    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:

    luban_10.jpg

    Although this example uses only two weights per criterion, it can still be used.

    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.

    luban_11.jpg

    Analyzing the new ranking. Note: for technical reasons this table is extracted from a different analysis.

    Ultimately, how do we retain the lowest amount of possible variants? Priority is to be given to those hypotheses that will satisfy both groups.

    luban_12.jpg


    Here is an example of a configuration that creates a game concept that merges two genres: racing and adventure:

    luban_13.jpg


    We can also identify a few hypotheses that did very well in one ranking but poorly in the other.

    luban_14.jpg


    Here for instance, the following criteria translate into a rally racing game with a storyline, a concept that did not score that high.

    luban_15.jpg


    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.

    luban_16.jpg


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:

Features

About the Author(s)

Pascal Luban

Blogger

Pascal Luban is a freelance creative director and game designer based in France. He has been working in the game industry as a game or level designer since 1995 and has been commissioned by major studios and publishers including Activision, SCEE, Ubisoft and DICE. In particular, he was Lead Level Designer on the 'versus' multiplayer versions of both Splinter Cell: Pandora Tomorrow and Chaos Theory, he designed CTF-Tornado, a UT3 mod multiplayer map built to showcase the applications of physics to gameplay, he was creative Director on Wanted – Weapons of Fate and lead game designer on Fighters Uncaged, the first combat game for Kinect. His first game for mobile platforms, The One Hope, was published in 2007 by the Irish publishers Gmedia and has received the Best In Gaming award at the 2009 Digital Media Awards of Dublin. Leveraging his design experience on console and PC titles, Pascal is also working on social and Free-to-Play games. He contributed to the game design of Kartoon, a Facebook game currently under development at Kadank, he did a design mission on Treasure Madness, zSlide's successful Free-to-Play game and completed several design missions for French and American clients. Pascal is content director for the video game program at CIFACOM, a French school focusing on the new media industry.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like