Xbox One maintains the true state of user-controller pairing in real time based on room awareness and explicit user intent to sign in. However, players expect a consistent, reliable gameplay experience that is resilient to some changes in user-controller pairing. Therefore, successful titles establish a subset of active users and controllers that are participating in the experience and cache their pairing state during gameplay. Then, as appropriate, this cache is updated to reflect the latest pairing state, thus ensuring that gameplay remains consistent and intuitive for users.
This section discusses how to manage players in your title, based on the following guidelines:
Specific guidance for managing players is based upon the gameplay style of your title:
Single context apps establish a single shared user context to use throughout the entire experience. These apps accept inputs from all controllers and ignore controller exchanges and handoffs. Examples of single context apps from Xbox 360 include Netflix, Facebook, and Internet Explorer.
The following table describes guidance for various scenarios involving single-context apps. Examples of single-context apps include Netflix and Facebook.
| Scenario | Guidance |
|---|---|
| Establish the player’s controller and user | The player’s user should be set to the app activation context’s recommended user (CoreApplicationContext.CurrentUser). If the app activation context has not provided a recommended user, your title should launch the Account Picker and set the player’s user based on the selection. |
| Indicate the player’s user | Your title should display the player’s user prominently. |
| Allow the player’s user to be switched | Your title should provide an entry point to the Account Picker. |
| Drive gameplay based on the player’s controller and user | Your title should accept input from all controllers, including those not operated by the player’s user. |
| Respond immediately to removal of the player’s controller or user | Since your title accepts input from any controller, there’s no need to respond to controllers being removed. However, if the player’s user is signed out, your title should re-establish the user by launching the Account Picker. |
| Update the player’s user and controller as appropriate | If your title is resumed after having been suspended, and the recommended user (specified by CoreApplicationContext.CurrentUser from the app’s activation context) has changed, your title should immediately switch the player’s user to the new recommended user. If your title is resuming from being constrained, it should listen for the CurrentUserChanged event and react accordingly to the CurrentUser change. |
Non-joinable apps, also called lobby apps, establish and cache the active players in a pre-game lobby screen. These titles listen to a subset of all controllers and optionally support multi-user experiences that are local to the console. Most Xbox 360 titles qualify as non-joinable apps, especially first person shooters—Halo, for example.
| Scenario | Guidance |
|---|---|
| Establish the player’s controller and user | Your title should display an engagement prompt (for example, “Press A to play!”) and wait for a controller to engage. The player’s controller should be set to the first controller that engages. The player’s user should be set to the engaging controller’s paired user. If the engaging controller isn’t paired to a user, your title should show the Account Picker and set the player’s user based on the selection.In the pre-game lobby screen, your title may establish additional players through similar engagement behavior. |
| Indicate the player’s user | Your title should display all players’ users prominently before any profile-related action is taken. |
| Allow the player’s user to be switched | Your title should provide an entry point to the Account Picker from the pre-game lobby and at logical points during gameplay, such as in between levels. |
| Drive gameplay based on the player’s controller and user | Your title should cache the player’s controller and user when gameplay begins, driving the player’s avatar through his controller’s input and taking profile-related action on his user account.Your title should ignore controller handoff events (such as Controller.ControllerPairingChanged Event) and allow the newly paired user to play as the player. |
| Respond immediately to removal of the player’s controller or user | If the player’s controller is removed, your title should pause gameplay and re-establish a new controller based on engagement (for example, “Press A to continue”). If the player’s user is signed out, your title should re-establish it by showing the Account Picker or by removing the player from the game. Be sure to check for these conditions when your title is resumed from being suspended. |
| Update the player’s user and controller as appropriate | If your title is resumed after having been suspended and the player’s user is paired to a different controller, that controller should become the player’s controller. The title can also show the Account Picker to have the player re-select his or her user, and the system will pair the engaging controller to it. |
Joinable apps are similar to lobby apps but also allow new players to jump in mid-game. Examples include fighting games and local multiplayer party games such as Kinect Adventures.
The following table describes guidance for various scenarios involving joinable apps. Example of joinable apps include fighting games and local multiplayer party games (for example, Kinect Adventures).
| Scenario | Guidance |
|---|---|
| Establish the player’s controller and user | Your title should display an engagement prompt (for example, “Press A to play!”) and wait for a controller to engage. The player’s controller should be set to the first controller that engages. The player’s user should be set to the engaging controller’s paired user. If the engaging controller isn’t paired to a user, your title should show the Account Picker and set the player’s user based on the selection.In the pre-game lobby screen and during gameplay, your title may establish additional players through similar engagement behavior. |
| Indicate the player’s user | Your title should display all players’ users prominently before any profile-related action is taken. |
| Allow the player’s user to be switched | Your title should provide an entry point to the Account Picker from the pre-game lobby and at logical points during gameplay such as in between levels. |
| Drive gameplay based on the player’s controller and user | Your title should cache the player’s controller and user when gameplay begins, driving the player’s avatar through his controller’s input and taking profile-related action on his user account.When a controller handoff event is raised, your title should assume that the newly paired user is playing as the player, but it should allow the user to establish himself as a new player based on engagement (for example, “Press A to switch to gamertag”). |
| Respond immediately to removal of the player’s controller or user | If the player’s controller is removed, your title should pause gameplay and re-establish a new controller based on engagement (for example, “Press A to continue”). If the player’s user is signed out, your title should re-establish it by showing the Account Picker or remove the player from the game. Be sure to check for these conditions when your title is resumed from being suspended. |
| Update the player’s user and controller as appropriate | If your title is resumed after having been suspended and the player’s user is paired to a different controller, that controller should become the player’s controller. Alternatively, your title can show the Account Picker to have the player re-select his or her user, and the system will pair the engaging controller to it. |