Les fonctionnalités multijoueur de Meta Quest permettent aux utilisateur·ices de se trouver, de s’inviter et de jouer ensemble dans divers jeux et applications. Ces fonctionnalités comprennent Destinations, Group Presence (Présence de groupe), Invites (Invitations), Rejoin (Rejoindre), Rosters (Listes), les notifications et des fonctionnalités axées sur le voyage telles que Invite Link (Lien d’invitation), Quick Invites (Invitations rapides) et Invite to App (Invitation à l’application).
Ce document présente les approches permettant de tirer parti de ces fonctionnalités afin de créer une expérience multijoueur fluide.
Qu’est-ce que le mode multijoueur ?
Le mode multijoueur sur Meta Quest est une expérience qui implique plusieurs utilisateur·ices (synchrones, asynchrones ou colocalisé·es) réuni·es pour coopérer ou se défier autour d’un objectif commun. Un contenu multijoueur bien conçu peut inciter les utilisateur·ices à revenir maintes fois dans votre application ou votre expérience.
Toute expérience multijoueur doit également proposer une structure de signalement permettant à ses utilisateur·ices d’informer les équipes de développement des comportements des joueurs et joueuses qui enfreignent le Code de conduite pour les expériences virtuelles (CCVE). Fournir des outils de gouvernance à vos utilisateur·ices vous permet de gérer la communauté de votre application et de la développer telle que vous l’envisagez pour votre application.
Expériences multijoueur synchrones, asynchrones et colocalisées
Une expérience multijoueur synchrone est une expérience dans laquelle les utilisateur·ices participent simultanément à une activité en temps réel. Elle est généralement réalisée en personne, via le mode multijoueur local, ou en ligne.
Une expérience multijoueur asynchrone est une expérience dans laquelle les utilisateur·ices n’ont pas besoin de jouer ou de participer simultanément à une activité pour progresser vers un objectif. Parmi les expériences multijoueur asynchrones, citons : la compétition pour une place sur un leaderboard, une application dans laquelle les utilisateur·ices peuvent télécharger du contenu qu’ils ou elles ont créé ou la contribution à un objectif commun que les autres utilisateur·ices pourront expérimenter et apprécier.
Une expérience multijoueur·se colocalisée est une expérience qui implique que les utilisateur·ices jouent à un jeu ou partagent une expérience dans le même lieu physique. Une expérience colocalisée fait appel à des éléments tels que les ancrages spatiaux partagés pour permettre des expériences de réalité mixte (MR). Les expériences de MR offrent une nouvelle façon de connecter les utilisateur·ices, en les aidant à interagir dans des espaces virtuels partagés et à profiter ensemble de nouvelles expériences multijoueur·se.
Mode multijoueur dans l’écosystème Meta Quest
Il a été démontré que les applications et les jeux multijoueur dans l’écosystème Quest maintiennent constamment un engagement élevé des utilisateur·ices et qu’ils sont des facteurs de motivation forts pour les faire revenir.
Dans cet écosystème, les applications multijoueur sont conçues sur la base du SDK Platform, qui contient des API permettant d’activer le mode multijoueur pour les applications immersives. De plus, l’intégration des API Platform permet d’accéder aux outils d’analyse et de test multijoueur dans le tableau de bord développeur·se
Fonctionnalités liées aux déplacements
Le SDK Platform contient également des fonctionnalités liées aux déplacements. Ces fonctionnalités permettent aux utilisateur·ices de se rendre vers des destinations et d’en revenir, et d’inviter leurs ami·es et leurs followers à les y rejoindre.
Les fonctionnalités liées aux déplacements dans votre application comprennent :
Destinations : les destinations sont des lieux configurables dans votre application qui peuvent être affichés à l’aide de la présence de groupe. Pour commencer à configurer des destinations dans votre application, consultez la présentation sur les destinations.
Group Presence (Présence de groupe) : comprend les informations suivantes qui sont gérées par l’application :
L’application dans laquelle se trouve la personne
Si elle se trouve dans un match
Si elle se trouve dans un lobby
Si elle se trouve dans une destination spécifique
S’il ou elle est joignable, c’est-à-dire qu’il ou elle est en mesure d’inviter des personnes à le ou la rejoindre dans sa destination actuelle
Invite to App (Invitation à l’application) : invitez les followers et les utilisateur·ices ayant récemment joué avec vous dans les lobbies existants.
Roster (Liste) : la liste permet aux utilisateur·ices de savoir quelles personnes participent au jeu à leurs côtés.
Rejoin (Rejoindre) : permet aux utilisateur·ices de décider de revenir ou non dans une session avec des ami·es après une interruption.
Webhooks : vous permettent de recevoir des notifications HTTP en temps réel des modifications relatives aux expériences multijoueur dans votre application.
Invite Link (Lien d’invitation) : lien d’invitation ouvert pouvant être envoyé à toute personne afin de se retrouver dans une application.
Quick Invites (Invitations rapides) : permettent aux développeur·ses d’intégrer des invitations dans leur expérience d’application sans superposition Meta Quest.
Cas d’utilisation des voyages
Les exemples suivants illustrent des expériences et des cas d’utilisation courants en matière de déplacement. Ils représentent la façon dont les utilisateur·ices peuvent normalement interagir avec les systèmes et fonctionnalités liés aux déplacements.
Remarque : ces exemples sont basés sur l’exemple d’application SharedSpaces, qui met en scène les utilisateur·ices test Alice et Bob. L’application comprend un ensemble de salons (rouge, vert, bleu et violet) associés à des destinations. En outre, l’application utilise Photon comme solution de gestion de réseau.
Inviter un·e ami·e dans un lobby
Ce flux comprend l’utilisation des destinations, de la présence de groupe, des invitations et des liens profonds :
L’utilisatrice A, Alice, lance l’application.
Lorsque l’application est lancée normalement, et non suite à une invitation, un évènement définit les informations de présence de groupe de l’utilisateur·ice.
Le nom de l’API de destination est défini sur la destination par défaut « Lobby » (Hall d’entrée) et la carte.
Comme Alice se rend dans le lobby et qu’elle ne possède pas encore d’ID de session pour le lobby, un nouvel identifiant aléatoire est créé. Dans cet exemple, nous utiliserons « Lobby_123 ». L’ID de session du match est vide.
L’étape suivante consiste à établir la couche de transport à l’aide de Photon. Nous rejoignons ou créons simplement un salon portant le même nom que son ID de session de lobby : « Lobby_123 ». Ce nom venant juste d’être créé, Alice sera la première dans le salon qui a été créé pour elle.
Maintenant au niveau d’UE4, elle commence à héberger le serveur UE4 sur son casque, car elle est la cliente principale de son salon Photon.
Alice envoie une invitation à Bob pour qu’il vienne la rejoindre dans le lobby_123.
Bob reçoit l’invitation dans le jeu ou dans Horizon Home.
Lorsque Bob accepte l’invitation, l’application est lancée avec un lien profond contenant la présence de groupe d’Alice, avec sa destination actuelle, « lobby », sa session de lobby, « Lobby_123 », mais sans ID de match.
La présence de groupe de Bob est mise à jour pour lui permettre d’utiliser cette même destination. Comme il s’agit d’une invitation à rejoindre un lobby, nous mettons également à jour l’ID du lobby de Bob afin qu’il soit identique à celui d’Alice.
Au niveau de Photon, le même flux est suivi par Bob : il essaie de créer ou de rejoindre un salon appelé « Lobby_123 ». Puisqu’il existe, il le rejoint simplement comme un client normal.
Au niveau d’Unreal Engine, l’application le connecte à Alice (l’actuelle cliente principale du salon Photon) en tant que client normal.
Rejoindre un match en cours
L’exemple suivant illustre le cas d’un·e utilisateur·ice rejoignant un match en cours.
Bob pénètre dans le salon bleu.
Lors de son entrée, son match_ID est défini sur l’ID du salon bleu. L’ID de ce salon privé est dérivé du lobby auquel il est rattaché, par exemple BlueRoom_for_lobby_123.
Le salon bleu est un salon privé associé au lobby d’Alice, lobby_123.
Les joueur·ses se trouvant dans un lobby spécifique peuvent rejoindre n’importe quel salon privé associé. Dans notre exemple, Bob rejoint le salon, ce qui a pour effet de créer ou de rejoindre le salon Photon nommé d’après son match_session_ID.
S’il est le premier à pénétrer dans ce salon, un nouveau salon Photon est créé et lui est affecté en tant que client principal actuel. En tant que client principal, Bob hébergera le serveur UE4 correspondant sur son casque. Bob initialise le serveur UE4, devient le premier client du serveur, et sa position de départ est établie.
Alice pénètre dans le salon bleu.
Son ID de match est défini sur celui du salon bleu, BlueRoom_for_lobby_123.
Elle se connecte au serveur de Bob, car ce dernier en est désormais l’organisateur. (UE4)
Elle est maintenant coprésente avec Bob.
Ils partagent les mêmes ID de lobby (lobby_123) et ID de match (BlueRoom_for_lobby_123).
Envoyer une invitation à un·e ami·e ou à un follower
Le processus suivant détaille le cas d’utilisation qui consiste à envoyer à un·e ami·e ou à un follower une invitation à rejoindre une destination au sein d’une application.
Dans le salon bleu, Alice ouvre la liste.
Elle et Bob sont représentés dans la même équipe et possèdent le même ID de lobby, lobby_123.
Alice clique sur le bouton d’invitation au bas de la liste, ce qui ouvre le panneau d’invitation.
Ensuite, elle sélectionne Charlie dans le panneau d’invitation.
Charlie reçoit l’invitation et l’accepte sur le casque Meta Quest, l’emplacement à partir duquel il l’accepte n’ayant aucune importance.
Un GroupPresenceJoinIntent est reçu et utilisé pour définir le nom de l’API de destination, l’ID du lobby et l’ID du match selon l’invitation.
Cela provoque l’évènement personnalisé NetworkLaunch. Ce lancement ayant démarré suite à une invitation, il utilise un message de lien profond contenant des informations sur la destination « Blue Room » (salon bleu), le lobby (lobby_123) et le match (BlueRoom_for_lobby_123).
Comme il s’agit d’une invitation à un match, la présence de groupe de Charlie est mise à jour avec les informations relatives à la destination et au lobby.
Cependant, l’ID de session du lobby de Charlie n’est pas modifié. Il conserve celui en sa possession, et s’il n’en possède pas déjà un, un nouvel ID aléatoire est généré. Sa session de lobby est donc différente de celle qui est partagée par Bob et Alice (par exemple, « Lobby_456 »).
Lorsqu’il se connecte au salon Photon nommé BlueRoom_for_Lobby_123, Charlie est informé que Bob en est l’organisateur. Charlie se connecte à Bob.
Alice, Bob et Charlie sont coprésents dans le salon bleu.
Inviter un·e ami·e ou un follower dans un lobby, puis se rendre ensemble à un match
Le cas d’utilisation suivant décrit un·e utilisateur·ice qui invite un·e ami·e ou un follower dans son lobby, formant ainsi un groupe, les deux personnes se rendant ensuite ensemble à un match (la destination).
Le groupe quitte le salon bleu et retourne dans le lobby.
Leurs ID de match sont définis sur null.
Alice et Bob retournent dans le lobby d’Alice avec l’ID de lobby partagé, lobby_123.
Charlie retourne seul à son ID de lobby unique, lobby_456.
Alice envoie une invitation à Charlie depuis son lobby. Elle souhaite aller avec lui à plusieurs matchs et revenir dans le même lobby.
Charlie accepte l’invitation.
Un GroupPresenceJoinIntent est reçu, lequel sert à définir les informations de présence de groupe.
Le nom de l’API de destination, l’ID du lobby (lobby_123) et l’ID du match sont basés sur le message de lien profond d’invitation.
Cette opération met à jour l’ID du lobby de la présence de groupe de Bob pour qu’il corresponde à celui d’Alice, lobby_123.
Il est ainsi associé au salon Photon.
La présence de groupe de Charlie est désormais mise à jour afin que son ID de lobby corresponde à celui d’Alice et de Bob.
Alice, Bob et Charlie sont coprésents dans le lobby, et peuvent désormais rejoindre les matchs ensemble et revenir dans le même lobby par la suite.
Tenter de rejoindre un match en cours ou pendant qu’un·e utilisateur·ice se trouve dans une destination non joignable
Le cas d’utilisation suivant décrit un·e utilisateur·ice qui tente de rejoindre un lobby ou une session en cours, ou alors qu’il ou elle se trouve dans une destination non joignable, comme le menu principal ou un menu d’options.
Alice voit que Bob se trouve actuellement dans un lobby de jeu via sa présence de groupe qui signale sa destination actuelle sur sa liste d’ami·es.
Bob se trouvant actuellement dans un état de jeu non joignable, sa présence de groupe is_joinable est définie sur false.
Dans la mesure où la présence de jeu is_joinable de Bob est définie sur false, Alice ne peut pas le rejoindre dans sa destination actuelle.
Si Bob se trouve dans une destination joignable alors qu’un match ou une session est en cours, sa valeur is_joinable peut rester sur true.
Lorsqu’Alice tente de le rejoindre, un GroupPresenceJoinIntent est reçu pour la destination actuelle de Bob.
La session de jeu actuelle de Bob est mise en pause. Lui et tous les autres membres du groupe sont renvoyés dans leur lobby.
Alice rejoint le salon, et son ID de lobby est défini de façon à correspondre à celui de Bob.
Alice est désormais coprésente avec Bob et tous les autres membres dans le lobby.
Alice et Bob peuvent maintenant jouer à un jeu ou utiliser une application en tant que groupe.
Questions/réponses
Question : Quelles sont les fonctionnalités multijoueur et pourquoi sont-elles importantes ?
Réponse : Les fonctionnalités multijoueur de la plateforme permettent à vos utilisateur·ices de coordonner et d’inviter d’autres personnes dans votre application, indépendamment de leur localisation. Les personnes invitées peuvent être dans votre application, ailleurs dans la VR, ou sur leurs appareils mobiles. Lorsque vous intégrez ces fonctionnalités dans votre application, vous élargissez votre audience, encouragez les nouveaux utilisateurs et nouvelles utilisatrices à participer, et réduisez les frictions entre joueur·ses.
Question : Comment intégrer des fonctionnalités multijoueur dans mon application ?
Réponse : Chaque application ayant ses propres besoins et le code existant pouvant nécessiter des solutions différentes, l’intégration du mode multijoueur dans un jeu est différente pour chaque équipe de développement. Cela dit, les cas d’utilisation décrits dans la section ci-dessus couvrent certains scénarios courants autour des fonctionnalités multijoueur·se, des déplacements et de la façon dont les utilisateur·ices interagissent avec eux.
Remarque : les fonctionnalités multijoueur·se sont prises en charge uniquement dans les applications immersives et ne sont pas disponibles dans les environnements non immersifs, tels que les applications à panneaux 2D ou les applications Android standard.
Question : les éléments étant très nombreux, comment faire pour donner la priorité à certaines fonctionnalités multijoueur·se plutôt qu’à d’autres ?
Réponse : Nous recommandons de commencer par implémenter les fonctionnalités de voyage, qui comprennent Destinations et Group Presence (Présence de groupe), Invite to App (Invitation à une application). Une fois cette opération terminée, vous pouvez implémenter des fonctionnalités telles que Invite Link (Lien d’invitation) et Roster (Liste) ainsi que d’autres fonctionnalités intermédiaires et avancées telles que Rejoin (Rejoindre), Invokable Error Dialogs (Boîtes de dialogue d’erreur invocables) et Webhooks.
Question : Qu’est-ce que les tests multijoueur et pourquoi sont-ils importants ?
Réponse : Les tests multijoueur sont des cas limites qu’une application multijoueur doit gérer une fois que les flux d’invitation et de participation du scénario idéal ont été développés (ils sont tout aussi importants à prendre en compte lors de l’implémentation du mode multijoueur). En tenant compte des scénarios les plus courants dans la section Cas de test, vous pouvez réduire les frictions avec les utilisateur·ices.