Chapter 2 defined the interaction model as the relationship between the player's inputs via the input devices and the resulting actions in the game world. You create the game's interaction model by deciding how the player's controller-button presses and other real-world actions will be interpreted as game world activities by the core mechanics. The functional capabilities of the various input devices available will influence your decisions (see "Input Devices" later in the chapter). There isn't room here to discuss button assignments in detail, so you should play other games in your genre to find examples that work well.
In practice, interaction models fall into several well-known types:
■ Avatar-based, in which the player's actions consist mostly of controlling a single character—his avatar—in the game world. The player acts upon the world through the avatar and, more importantly, generally can influence only the region of the game world that the avatar currently inhabits. An avatar is analogous to the human body: To do something in our world, we have to physically take our bodies to the place where we want to do it. That doesn't mean an avatar must be human or even humanoid; a vehicle can be an avatar. To implement this mode, therefore, many of your button-assignment decisions will center on navigation (see "Navigation Mechanisms" later in the chapter).
■ Multipresent (or omnipresent), in which the player can act upon several different parts of the game world at a time. In order for him to do so, you must give him a camera model that permits him to see the various areas that he can change; typically, an aerial perspective. Chess uses a multipresent interaction model; the player may ordinarily move any of his pieces (which can legally move) on any turn. Implementing this mode requires providing ways for the player to select and pick up objects or give orders to units.
■ In the party-based interaction model, most commonly found in role-playing games, small groups of characters generally remain together. In this model, you will probably want to use point-and-click navigation and an aerial perspective.
■ In the contestant model, the player answers questions and makes decisions, as if a contestant in a TV game show. Navigation will not be necessary; you will simply assign different decision options to different buttons.
■ The desktop model mimics a computer (or a real) desktop and is ordinarily found only in games that represent some kind of office activity, such as business simulations.
A coherent design that follows common industry practice will probably fit into one of these familiar models. You can create others if your game really requires them, but if you do so, you may need to design more detailed tutorial levels to teach your player the controls.