Mise en réseau sur écran scindé et GameShare dans Survival Kids

Cet été, Unity a sorti son premier jeu, créé en étroite collaboration avec l'éditeur partenaire KONAMI. Survival Kids est une mise à jour amusante du classique jeu pour enfants qui a été lancé en tant que premier titre Nintendo SwitchTM 2.

Le jeu a été entièrement conçu sur Unity 6, donc l'équipe de développement travaillait avec un nouveau logiciel pour lancer le jeu sur une nouvelle plateforme – un énorme défi. En plus de cela, le jeu peut être apprécié dans une variété de configurations réseau, de sorte que la petite équipe Unity travaillant sur le projet a dû créer une architecture Multiplayer robuste qui prendrait en charge ces options.

Découvrez le premier volet de l'histoire de la mise en réseau Multiplayer pour Survival Kids, où nous racontons comment les fondamentaux derrière l'architecture réseau du jeu se sont réunis. Cet article développe cette base pour montrer comment l'équipe a créé l'écran scindé du jeu et les capacités GameShare Nintendo Switch 2.

Nintendo Switch est une marque commerciale de Nintendo.

Après avoir résolu de nombreux problèmes dans l'architecture réseau du jeu, nous avons commencé à réfléchir à la façon dont nous allions créer un écran scindé, qui n'est pas fourni prêt à l'emploi dans Netcode for Entities. C'était un défi différent. Avec l'écran scindé, il doit y avoir plus d'un joueur, mais ces joueurs appartiennent à un client.

Netcode for Entities part du principe qu'il y a un joueur par client. S'il y a un jeu distinct, avec une console distincte qui s'y connecte, alors il a un joueur. Lorsque cela change et qu'il y a en fait deux ou trois joueurs, il n'est pas possible d'envoyer les données pour chaque joueur individuel. Ils doivent être envoyés comme un tout.

Nous avons créé un lecteur d'entrée virtuel que personne ne peut voir. Il est totalement invisible, mais il collecte toutes les données pour tous les joueurs locaux, jusqu'à quatre (même si au final nous n'avons pas fait d'écran scindé à quatre joueurs). Il gère toutes les entrées qui arrivent, puis il envoie toutes ces entrées sur le serveur à chaque image.

Dans le jeu, les joueurs ne gèrent pas leurs propres entrées. Le joueur virtuel imaginaire indique quelle est l'entrée pour une image. Auparavant, Netcode for Entities partait du principe qu’un joueur était responsable d’obtenir ses données et de les utiliser pour effectuer tous ses mouvements. Mais il y a ici cet autre joueur qui ne fait aucun mouvement mais détient toutes les données pour tout le reste.

L'écran scindé était le principal défi du point de vue du réseau. Pour éviter d'avoir un problème de caméras multiples, nous avons commencé par avoir un deuxième joueur qui courait partout pendant que la caméra restait avec le premier joueur. Cela s'est réalisé assez rapidement, mais nous avons rencontré d'autres problèmes, comme comment configurer une deuxième caméra ? Comment garder une caméra à gauche de l'écran et l'autre à droite de l'écran ? Nous avons également dû résoudre des problèmes d'IU, car il y a beaucoup d'IU qu'un seul joueur peut voir. Par exemple, si un joueur est devant un journal, il verra un petit bouton d'invite qui dit « Hé, appuyez sur X pour ramasser ce journal », mais bien sûr, vous ne voulez pas que l'autre joueur le voie.

Nous avons dû trouver comment masquer l'IU pour que l'autre joueur ne le voie pas. Nous avons utilisé des couches pour cela, mais notre correction concernait plus l'IU que le réseau. Nous avions décidé que nous voulions au final verrouiller le jeu à deux joueurs sur écran scindé pour une meilleure expérience de jeu. Même sur un grand écran, il ne peut y avoir que deux joueurs locaux. Nous pouvions en faire quatre sur un écran scindé en interne, et nous l'avons conservé pendant un bon moment car c'était une excellente façon de tester les performances, puisque chaque joueur ajoute un peu plus de traitement, un peu plus de rendu, un autre joueur à simuler.

L'une des fonctionnalités pendant le développement de la Nintendo Switch 2 est GameShare. En fait, vous envoyez un flux vidéo à une autre console – en réalité, il s'agit juste d'un écran scindé du point de vue du réseau – sauf que le système envoie une caméra à une autre console au lieu de le rendre sur un écran.

Notre écran scindé à quatre joueurs a servi de base à notre approche du mode GameShare. Nous pouvons connecter autant de joueurs que nous le souhaitons tant que les performances sont correctes et que nous pouvons diffuser des vidéos sur cette console. La principale raison pour laquelle nous ne voulions pas faire d'écran scindé à quatre joueurs était juste la taille de l'écran. À moins d'avoir un téléviseur volumineux, il est vraiment difficile de voir les Windows, mais si vous avez votre propre console, la vidéo peut être visionnée en streaming.

Nous avons fait des efforts considérables pour nous différencier de notre mode écran scindé à deux joueurs afin de pouvoir prendre en charge un troisième joueur supplémentaire dans GameShare. Vous pouvez avoir un hôte et deux invités tout en offrant aux joueurs une excellente expérience et des performances fluides. Nous n'étions pas prêts à abaisser nos normes à ce sujet, mais nous avons tout de même pu utiliser l'architecture à écran scindé pour alimenter GameShare.

Une fonctionnalité vraiment utile que nous avons ajoutée était une commande de débogage. Nous avons un menu de développement, vous pouvez donc appuyer sur un bouton, appeler le menu, puis saisir des commandes dedans. C'était pratique, car cela nous a permis d'exécuter beaucoup de choses de débogage. Tout est compilé hors du jeu final, donc bien sûr, personne ne pouvait le faire dans le jeu final que les gens achètent et auquel ils jouent. Mais l'un des modes que nous avions en écran scindé était que vous pouviez dupliquer le lecteur principal. Cela vous permettait d'avoir un écran scindé où un contrôleur exécute les deux joueurs. C'était un excellent moyen de tester l'écran scindé sans avoir besoin d'avoir beaucoup de contrôleurs autour, ce qui a facilité les tests.

La configuration de l'écran scindé a également exécuté tout le code réseau normal que nous avons effectué. Les joueurs étant séparés les uns des autres, le serveur enverrait des informations pour montrer comment fonctionne le jeu en ligne. Mais il est également possible de tester si le code a fonctionné en mode Multiplayer sans connecter un joueur à un autre client en lançant le mode écran scindé avec un autre contrôleur dans l'éditeur pour y jouer. Il n'est pas nécessaire d'effectuer une nouvelle compilation puisqu'il est possible de tester le code sur écran scindé en tant que proxy pour un jeu en ligne normal.

Il y avait deux autres outils Unity que nous avons trouvés très utiles, même si nous ne les avons utilisés qu'à la fin du projet. Unity 6 inclut de nouveaux outils Multiplayer Play, qui nous permettent de tester sans compilation de joueur distincte.

Pour ouvrir l'Éditeur, il faut plus d'une heure pour créer une compilation de joueur propre, car il y a tellement d'éléments artistiques et d'autres informations. Tester le code avec un lecteur distant signifie donc attendre au moins aussi longtemps. Ce n'est pas particulièrement bon pour itérer. Mais le mode Multiplayer Play vous permet de faire tourner efficacement une autre fenêtre, comme une autre version virtuelle de l'éditeur, et de vous connecter comme ça.

Netcode for Entities dispose également d'outils en mode lecture pour simuler de mauvaises connexions réseau. Vous pouvez spécifier et simuler un niveau de ping spécifique, disons un ping de 300 millisecondes, un aller-retour vraiment horrible pour simuler ce que ce serait de jouer avec un ami qui a attaché son téléphone à son ordinateur portable dans un aéroport et s'est connecté au jeu de cette façon. Ensuite, vous pouvez tester cela dans l'Éditeur pour savoir à quel point il est instable. Parfois, cela ne fonctionne pas sur une connexion réseau qui perd des données et dépose des paquets, et nous pourrions simuler cela facilement.

Ces tests se produisaient tout le temps. Pendant un certain temps, nous avons eu une règle selon laquelle personne n'était autorisé à jouer dans l'éditeur avec le simulateur éteint. Tout le monde devait jouer avec une sorte de décalage simulé, car aucun de nos joueurs n'allait jouer sur une connexion parfaite. De cette façon, nous ne pourrions jamais nous leurrer en croyant qu'un bureau à très haut débit était représentatif.

Au final, tous ces tests ont porté leurs fruits : nous avons pu livrer un jeu fluide et performant à 60 FPS sur des réseaux et des configurations Multiplayer vraiment différents. Depuis la sortie du jeu, il y a quelques semaines, nous avons vu des joueurs continuer à s'impliquer en ligne via Lobby et Relay, avec un peu de chance de bénéficier d'une expérience de jeu fluide et robuste, quelles que soient les conditions de leur réseau domestique.

Découvrez les autres opus de notre série de blogs et plongez dans la production de Survival Kids :
- "Graphismes et astuces de rendu par Survival Kids"
- "Disposition des niveaux et flux de production du terrain dans Survival Kids"
Inside the Survival Kids Multiplayer Network Infrastructure

Pour en savoir plus sur les projets Made with Unity, consultez la page Ressources .