Game Design: First Look

The Situation Model of a game is player-centric. It describes how the player is playing through the game. It breaks the player's view of a game down into discreet situations, and depicts how the player flows from one situation to another. It treats the game itself as a black-box process (though one that the player can learn about), one that takes inputs and maps them to results that the player can process.

This is a very useful tool in the game designer's arsenal. However, it is not enough, because the game designer does not produce bare situations. The game designer produces a game design, which generates those situations.

We defined the term "game design" before, back here when we modified the original formulation of the Situation Model. We said that the game design is "the set of rules, the game's initial Situation, and potentially state information (about what has happened before, etc) that defines the mechanism for generating the Game Input to Result mapping for a Situation." This was from the perspective of the Situation Model.

From the perspective of the designer, however, things change. Under the Situation Model, which is focused on a single player, the opponent(s) in a multiplayer game would also go under the classification of "game design". This is easily explained; many people find playing online multiplayer games to be onerous because of the quality of opponents (griefers, droppers, etc). The quality of a multiplayer game is judged in part by the people who play it. Non-online multiplayer games tend to be seen as better, simply because people do not tend to behave inappropriately as they would online.

So it makes sense from a single player's perspective to group opponents under game design. However, the designer cannot. A game designer must treat the individual players altogether as part of the external world that needs to be served by the game's design.

Therefore, we will redefine game design slightly, from the perspective of the game designer. Game Design is:

The set of rules, the game's initial Situation, and potentially state information (about what has happened before, etc) that defines the mechanism for generating the Game Input to Result mapping for a Situation for any and all players playing the game.

We will divide game design into 2 distinct sections: Game Mechanics, and Game Implementation.

The Game Mechanics are the set of rules governing the behavior of objects in the game. In chess, the mechanics are simply the rules of turn-based movement, capturing pieces, moving pieces, and victory/loss conditions. As a more complex example, the game mechanics of Super Mario Bros are the ability to run on the ground, jumping and gravity, the fact that the player can hit objects from below to release items, how enemies can move, that a super mushroom makes Mario Super which has a number of attributes associated with it, etc.

The Game Implementation refers to the initial condition, the starting situation, as well as the specific application of mechanics to the particulars of the game itself. In the case of chess, all this refers to is the initial condition of the board and who goes first. In the case of Super Mario Bros, on the other hand, this refers to the specific design of each level down to the last brick, the behavior of each kind of enemy, the placement of enemy spawn locations, the fact that the game is broken up into 8 worlds made of 4 levels each, etc.

Some games emphasize one facet over another, and the character of the game can be derived from this. For example, most competitive multiplayer games are very heavily driven by game mechanics. Level design, which falls under implementation, is crucial as well, but poor mechanics can mean that there this an imbalance in the play that no level design can fix. Take StarCraft for example. Almost 10 years old, and it is still played as a professional sport in South Korea. This is due to its incredibly robust game mechanics. Level design is entirely secondary to the effectiveness of this game. Chess and Go are also very focused on mechanics, with very thin layers of implementation. This includes videogames like The Sims and SimCity; you get starting conditions and then you proceed to do as the mechanics allow.

Other games focus more on implementation than mechanics. Adventure games, for example, are much more about level design and layout than the specifics of the mechanics. RPGs need robust mechanics, but it is the specific use of these mechanics that most determines whether the game works well or not.

It is sometimes difficult to know where the line is between implementation and mechanics. Taking Civilization as an example, the existence of the tech tree is clearly a mechanic. The fact that all players have the same tree is a mechanic, as is the fact that each tech has a specific research cost. But are the particular technologies themselves part of the mechanics or the implementation? There is an argument to be made for both.

The distinction, in the hard-line sense, is generally best used in service to the game designer. From an analysis perspective, where exactly the implementation ends and mechanics begin is not very important, though it can be useful when talking about the game. For the designer who must then build the game, it can be very important, particularly with regard to how the game is built, playtested, and adjusted.

Testing the mechanics first for mechanics-heavy games is vital. As such, designing these games can involve folding some of what might be considered implementation into those mechanics. Whereas for implementation-heavy games, mechanics testing is, while useful, not always the best way to spend time. At which point, playtesting should be focused on the implementation.

BTW, this is why genres are important to many commercial designers. Not only does it give gamers an idea of what the game will be like, it gives designers a set (or partial set) of mechanics that the designer does not have to playtest to see if they work. Furthermore, with genres, designers already know how to use those mechanics to achieve certain effects, so the implementation is simpler.

AI is, in all cases, part of the implementation, however. AI is never a game mechanic; what the AI can do may be. This does not mean that game AI must be treated like another player. Most single-player games treat enemy AI as obstacles. In the case of platformers, they can even be used by clever players to get to locations that would be otherwise inaccessible.

However, AI can be treated as separate players. This is usually true for bot-type AI in multiplayer games, where bots fill in for humans. In such games, the AI lives at the very top of the implementation, and most of the rest of the implementation does not consider the presence of AI bots as being anything particularly special.

This is all just a lead-in to looking at exactly what game design is and how it relates to creating the Interactive Loop.