Visibilité des sessions de jeu
L’accès aux sessions Multiplayer Session Directory (MPSD) est régi par deux paramètres : la visibilité et la possibilité de jonction de la session. Ces paramètres permettent de limiter l’accès aux sessions au niveau de MPSD. Le premier aspect du contrôle d’accès est la visibilité de la session. La visibilité de la session est une constante définie au moment de la création de la session. La visibilité de la session est généralement définie dans le modèle de session et détermine quels types d’utilisateurs disposent d’un accès en lecture et en écriture à une session. Les valeurs du paramètre de visibilité sont les suivantes.- Open : tous les utilisateurs peuvent lire et écrire dans la session.
- Visible : tous les utilisateurs peuvent lire la session, mais seuls les joueurs ayant rejoint la session ou réservés peuvent y écrire.
- Private : seuls les joueurs ayant rejoint la session ou réservés peuvent la lire ou y écrire.
Définir la visibilité sur « private » peut obliger le joueur invité à réessayer l’appel
join(). Si une invitation est envoyée via l’interface utilisateur de la plateforme, elle peut être reçue par un autre joueur avant que ce joueur n’ait été réservé dans la session. Cette condition de concurrence peut faire échouer un appel join() pour un joueur invité, car les sessions « private » ou « visible » exigent une réservation pour le joueur qui rejoint.S’il n’existe aucune réservation, une erreur d’accès à la session (HTTP/403) est générée. Le joueur invité doit alors réessayer l’opération join(). Cependant, les nouvelles tentatives ne doivent pas avoir lieu plus d’une fois toutes les cinq secondes. Nous recommandons aux titres de définir la visibilité de la session sur « open » afin d’éviter les conditions de concurrence pendant le flux de jonction d’un joueur.Possibilité de jonction des sessions de jeu
Le second aspect du contrôle d’accès est la possibilité de jonction. Elle peut être définie de manière dynamique pendant la durée de vie de la session et détermine quels types d’utilisateurs peuvent rejoindre une session. Les valeurs de la possibilité de jonction de la session sont les suivantes.- None : (valeur par défaut) aucune restriction ne s’applique quant aux personnes pouvant rejoindre la session.
- Local : seuls les utilisateurs locaux peuvent rejoindre la session.
- Followed : seuls les utilisateurs locaux et les utilisateurs suivis par d’autres membres de la session peuvent rejoindre la session sans réservation.
La possibilité de jonction des sessions de jeu n’est pas reflétée dans l’interface utilisateur de l’application Party. Même si la possibilité de jonction est restreinte, l’interface d’invitation de l’application Party et
ShowSendInvitesAsync autorisent les invitations à la session de jeu.Possibilité de jonction des groupes de jeu
En plus de contrôler la session MPSD, le titre contrôle également l’état de possibilité de jonction du groupe de jeu. Ce paramètre permet de limiter l’accès au groupe de jeu au niveau du groupe. La possibilité de jonction du groupe peut être modifiée dynamiquement lors de la création du groupe de jeu. L’état de possibilité de jonction d’un groupe de jeu est reflété dans l’interface d’invitation de Party. L’état de possibilité de jonction peut être défini comme suit :- Invite-only : ce paramètre exige une invitation pour rejoindre le groupe de jeu.
- Joinable by Friends : (valeur par défaut) ce paramètre exige une relation d’amitié pour qu’un joueur puisse rejoindre le groupe de jeu (pour rejoindre un groupe, un membre du groupe doit suivre le joueur qui rejoint).
La possibilité de jonction du groupe n’influe pas sur la possibilité de jonction de la session. Elle est cependant reflétée dans l’interface utilisateur de l’application Party. Les joueurs peuvent modifier manuellement la possibilité de jonction du groupe dans l’application Party, en dehors d’un titre.
Recommandations
Les recommandations suivantes s’appliquent aux scénarios de titre les plus courants. Les titres doivent suivre ces paramètres dans la mesure du possible, et utiliser une logique interne au titre pour décider en dernier ressort, de manière définitive, si un nouveau joueur est admis dans la session.Visibilité recommandée pour les sessions de jeu : open
Les sessions de jeu ouvertes ne nécessitent pas de réservations de joueurs. Cela simplifie le flux des invitations. L’arbitre ou l’hôte de la session ne réserve pas de joueurs dans le document de session après l’envoi d’une invitation. Il se contente de suivre localement les joueurs invités. Cela permet aux joueurs de se connecter immédiatement à l’hôte et de déterminer s’ils doivent rejoindre une session, s’ils sont refusés ou s’ils doivent patienter (si les joueurs en attente sont pris en charge). L’arbitre ou l’hôte a l’autorité finale : il répond au nouveau membre et lui indique s’il doit rester dans la session ou la quitter.Cela exige que le joueur invité lance un titre et se connecte à l’arbitre ou à l’hôte avant que la décision finale ne soit prise. Il est acceptable d’afficher un message d’erreur à l’utilisateur si une session est pleine ou si une invitation a été refusée.
Pour établir une connexion à l’arbitre ou à l’hôte, une adresse d’appareil sécurisée (Secure Device Address) est requise. Le
HostDeviceToken de la session doit être utilisé pour indiquer quel membre est l’arbitre ou l’hôte actuel d’une session et à quelle adresse d’appareil sécurisée un joueur invité doit se connecter.Possibilité de jonction recommandée pour les sessions de jeu : valeur par défaut (non définie)
Actuellement, la possibilité de jonction des sessions de jeu n’influe pas sur l’interface utilisateur de l’application Party et n’est pas présentée à l’utilisateur. Pour simplifier le flux du titre, la possibilité de jonction de la partie doit rester à sa valeur par défaut, et toute l’autorité en matière de jonction doit être gérée par l’arbitre ou l’hôte.Possibilité de jonction recommandée pour les groupes de jeu
La possibilité de jonction des groupes de jeu dépend du type de session qu’un titre cherche à proposer à un utilisateur. Les deux scénarios sont les suivants.- Partie ouverte : pour une partie ouverte, la possibilité de jonction du groupe de jeu doit rester à sa valeur par défaut, « Joinable by Friends ». Cela permet aux amis de rejoindre le groupe de jeu (et, par extension, la session de jeu) sans invitation.
- Partie privée : pour une partie privée ou fermée, la possibilité de jonction du groupe de jeu doit être définie sur « invite only ». Cela empêche d’autres joueurs de rejoindre le groupe (et, par extension, la session de jeu) sans invitation.
Les joueurs peuvent modifier manuellement la possibilité de jonction d’une session de jeu via l’application Party.
Taille maximale de session
Le nombre maximal de membres d’une session peut servir à limiter le nombre de joueurs qui rejoignent une session de jeu. Cependant, cette limite peut faire apparaître un emplacement libre comme occupé dans certains scénarios de déconnexion. Par exemple, si un joueur est déconnecté à la suite d’une panne réseau ou d’une coupure de courant, ce délai n’est pas immédiatement reflété dans la session. Le membre est défini comme inactif dès que le service Presence détecte la déconnexion (jusqu’à 20 secondes). Le joueur est ensuite retiré une fois le délai d’expiration inactive écoulé. En comparaison, un maillage de pairs qui utilise une pulsation (heartbeat) pour détecter une déconnexion en a souvent connaissance en deux à trois secondes et peut libérer immédiatement l’emplacement du joueur. Cependant, l’arbitre ou l’hôte ne peut pas retirer d’autres membres. Pour résoudre ce problème, le nombre maximal de membres d’une session doit toujours être supérieur au nombre maximal de joueurs que le titre prend réellement en charge. Par exemple, si le nombre de joueurs est de 8, le titre doit définir la taille maximale de session sur 12. Ainsi, de nouveaux joueurs peuvent rejoindre la session, même si les joueurs précédents n’ont pas encore expiré. L’arbitre ou l’hôte détermine si la session est pleine, puis définit une propriété de session personnalisée qui indique si de nouveaux joueurs peuvent encore la rejoindre (IsFull : “true”).
Cela permet aux joueurs qui rejoignent de vérifier rapidement si la session est joignable.
L’arbitre ou l’hôte doit également tenir à jour une propriété personnalisée qui indique, par index, quels membres ont expiré (par exemple, TimedOutPlayers : “3, 5, 9”).
Cela permet aux nouveaux joueurs d’identifier correctement les membres actuels de la session.
Notification des joueurs en attente
Un titre peut prendre en charge des joueurs en attente en gérant une liste de joueurs en file d’attente, en plus du groupe de jeu. Lorsqu’un joueur se connecte à l’hôte alors que la session de jeu est pleine, il est ajouté à la liste d’attente interne de l’hôte. Le joueur en file d’attente ne rejoint pas la session de jeu, mais reste dans le groupe de jeu. Pour réduire le trafic réseau, le joueur en attente se déconnecte alors de l’hôte.- Lorsqu’un emplacement de la session de jeu se libère pour le joueur en attente, l’arbitre ou l’hôte ajoute une réservation pour ce joueur en appelant XblMultiplayerSessionAddMemberReservation.
-
À ce stade, le joueur en attente n’a pas encore connaissance de cette réservation. Par conséquent, l’arbitre ou l’hôte doit appeler la méthode
PullReservedPlayersAsync. Cela déclenche une notification d’interface utilisateur ou une notificationGameSessionReadypour tous les joueurs réservés, selon la configuration des notifications et l’état de focus du titre. - Le nouveau joueur se reconnecte à l’hôte lorsqu’il reçoit cette notification, puis rejoint la session.
Les joueurs sont automatiquement retirés du groupe de jeu si le titre est suspendu ou arrêté. Les joueurs ne reçoivent alors plus aucune notification.
Flux multijoueur client


