Frequently-asked questions concerning users, controllers, and pairing.
Even though the system provides real-time information on user-controller pairing based on room awareness, players expect a reliable experience that’s robust to certain changes in the environment. For example, during a single player game, users expect to be able to pass the controller to a friend to get their help on a certain section of gameplay. Without the ability to lock the player’s active user and controller, handing off the gamepad could cause a jarring experience for players: loss of user context during or after the transition.
Yes! It’s possible for controllers not to be paired to a signed-in user. For example, unidentified human bodies are represented as BodyController objects that are not paired to a User object. SmartGlass devices, acting as navigation controllers and operated by users who have not signed in to the console, are another example, and gamepads that can’t be correlated to a signed in user are also not paired to a User object. In all of these cases, titles can still accept input from these controllers. By adhering to the guidance, described earlier, on establishing and managing players, your title can gracefully facilitate pairing these controllers to users and drive gameplay.
Biometric identity and automatic controller pairing rely on bodies and gamepads being tracked by Kinect. These forms of system-provided user-controller pairing do not function if the Kinect sensor is disconnected. Players are still likely to sign in through the Account Picker on Home, pairing their gamepad to the selected user. By the time your title launches, it’s likely that gamepads are paired to users. Following the prioritized order of rules for establishing an active user will still allow you to establish players gracefully, with a fallback of using the Account Picker if the controller isn’t paired to a signed in user at the time.
Once gameplay begins, we recommend that your title follow the same guidelines. The absence of a Kinect sensor doesn’t change players’ expectations about how your title should function. The title must drive gameplay based on the locked-in active user and controller and must respond immediately if the active controller or user is removed. The title must update the active controller and user at appropriate times based on pairing.
Players may choose to play as other users at the beginning of gameplay. During gameplay, players may hand their active controller to another user to play for them temporarily. The preceding guidelines account for both of these scenarios. First, by adhering to these guidelines, you offer the player a choice of switching profiles and confirmation of the selected profile before gameplay begins. During gameplay, your active user is locked despite another person holding the gamepad. This guarantees that no matter who is playing, the profile receiving credit remains consistent, providing a predictable, reliable experience for your players.
In addition to pairing users automatically to their human bodies, the BodyController.BiometricUserId Property can be used as a unique identifier of the human body based on its biometric identity. This value is set initially to 0 for bodies that haven’t been identified. Once recognition occurs, the value is set to the unique identifier of the biometrically enrolled user on that console. The BodyController.BiometricUserChanged Event is also raised when recognition occurs.
Although this property appears very similar to the user pairing, it offers your title a few unique advantages. First, the system assigns the BiometricUserId property when the user is recognized biometrically, even if the user isn’t signed in at the time. Additionally, a user may choose to play as another user by selecting the other’s profile in the Account Picker (resulting in a pairing to that user). In this case, BiometricUserId provides a consistent and unique identifier for the user, based on the player’s biometric identity. This identification makes it easier to facilitate fast-paced jump-in-jump-out experiences, where the title needs to track players as they leave and re-enter the field of view.
The User.Controllers Property returns the list of Controller objects paired to the User object while BodyController.AssociatedControllerIds returns the IDs of controllers associated with a BodyController object. These two lists are usually the same for signed-in users: after a user picks up a gamepad, both his User object and his BodyController object are updated to show the pairing of the gamepad.
These two lists differ when an unknown body controller, such as one belonging to someone who is not signed in, picks up a gamepad. For example, suppose Player A is signed in and hands his gamepad to Player B, who is not signed in. Player B, because she is not signed in, would be represented only as a body controller and not a User object. Upon picking up the gamepad, Player B’s BodyController.AssociatedControllerIds is updated to include the gamepad ID. However, Player A’s User.Controllers does not change, and Player A remains paired to this gamepad.
To summarize, BodyController.AssociatedControllerIds contains the direct association between a body and any controllers that person is physically using, regardless of User objects. In contrast, Users.Controllers maintains the pairing between User objects and the controllers to provide consistency and robustness against unknown controllers.
Although it isn’t directly related to user and input identity, Kinect Split-Screen Play, an XR, depends on the controller and body controller tracking technologies covered in this topic. This XR requires titles that have vertical, side-by-side split-screen to match the screen location relative to the user’s physical ordering in the playspace. For example, in two-player side-by-side split-screen, the user on the left should control the left part of the screen, and the player on the right should control the right part of the screen.
Best practice: The title should maintain the screen ordering until the next logical point for updating it, such as after a level ends.
Titles can use the Controller.GetControllersOrderedLeftToRight Method to poll the order of players from left to right—from the player perspective—and generate the initial screen ordering. They can use the Controller.ControllerOrderChanged Event to update the screen order. The ordered controllers can be filtered as TrackedAcessories (supported non-body controllers) or TrackedBodies (body controllers).