À l'intérieur de l'infrastructure réseau multijoueur de Survival Kids

Cet été, Survival Kids a été lancé en tant que sortie du premier jour pour Nintendo Switch™ 2. Le jeu a été entièrement construit sur Unity 6, marquant le tout premier projet de développement de bout en bout de Unity, en travaillant en étroite collaboration avec le partenaire éditeur KONAMI.

Développer pour une nouvelle plateforme dès le premier jour est un énorme défi, mais la petite équipe interne qui a construit ce projet comprenait des développeurs Unity expérimentés, dont beaucoup travaillent dans Unity et sur des jeux depuis des décennies. Ce blog fait partie d'une série continue plongeant dans la façon dont le jeu a été créé, comment ce travail a alimenté l'engagement de Unity envers la vérification de production, plus les leçons que d'autres développeurs de jeux Unity peuvent tirer et appliquer à leurs propres projets.

C'est le premier épisode d'une série continue sur les coulisses explorant les leçons d'équipe tirées du travail sur Survival Kids.

Nintendo Switch est une marque déposée de Nintendo.

Survival Kids a été construit par une très petite équipe au sein de Unity. Le groupe principal comptait environ 10 développeurs de diverses disciplines (artistes, ingénieurs et designers). À notre apogée, nous étions environ 20 alors que des personnes d'autres équipes Unity se joignaient à nous. Par exemple, Steven, notre ingénieur en rendu, a beaucoup travaillé avec nous, mais il n'était pas toujours sur le projet.

En tant que petite équipe, nous avions certains avantages, cependant. Les ingénieurs étaient très expérimentés – la plupart d'entre nous écrivent des jeux depuis environ 20 ans, principalement dans l'espace AAA, donc nous avons appris beaucoup de leçons et avons fait beaucoup d'erreurs. Et bien sûr, nous avons vraiment de l'expérience dans Unity car la plupart d'entre nous sont ici depuis un certain temps.

Certains d'entre nous ont également travaillé sur des projets clients dans le cadre des équipes de support de Unity comme les Services Professionnels/Accelerate Solutions, maintenant Unity Studio Productions. Nous conseillons les clients sur la façon d'optimiser leurs projets et même nous intégrons aux équipes de projet pour travailler à leurs côtés et les aider à résoudre leurs problèmes techniques difficiles, donc nous sommes assez bien informés sur les erreurs que les studios font souvent et comment les corriger. En travaillant sur Survival Kids, nous avons pu architecturer le projet et le mettre sur la bonne voie dès le départ car nous savions où seraient tous les pièges, et cela nous a fait gagner beaucoup de temps et de ressources.

Aujourd'hui, je veux plonger dans l'architecture réseau du jeu. Nous avons utilisé Unity pour gérer le réseau multijoueur, et Survival Kids offre aux joueurs plusieurs façons de jouer au jeu, toutes à partir de la même base de réseau. Alors plongeons dans la façon dont cela s'est mis en place, et j'espère que certaines de ces informations pourront vous aider dans vos projets également.

Survival Kids peut être joué de plusieurs façons : en solo, en coopération locale et en ligne avec des amis. Sur le Nintendo Switch™ 2, les joueurs peuvent également utiliser GameShare pour diffuser la vidéo sur une autre Nintendo Switch 2 ou même une Switch originale, puis jouer en multijoueur avec quelqu'un sur la télévision ou un appareil, ce qui est vraiment cool.

Nous voulions que notre configuration gère tout cela et d'autres combinaisons. Par exemple, vous pourriez avoir deux joueurs jouant en écran partagé sur une télévision connectée à deux autres joueurs jouant en écran partagé sur une autre télévision – donc quatre joueurs utilisant deux appareils. Cette flexibilité était quelque chose que nous voulions vraiment intégrer dans l'architecture pour permettre de jouer de nombreuses façons différentes.

Pour ce faire, nous avons décidé d'utiliser Netcode for Entities. Une fois que nous avons présenté le concept de Survival Kids à KONAMI, nous sommes directement passés au prototypage pour trouver le plaisir de notre jeu multijoueur. Nous avons utilisé un projet existant comme point de départ, un que j'avais écrit précédemment comme preuve de concept pour montrer comment nous pourrions utiliser Netcode for Entities comme réseau backend, puis écrire une couche GameObject par-dessus pour tirer parti des Prefabs et des animations. Tout le monde dans l'équipe n'avait pas d'expérience avec les Entities, donc nous avons décidé d'utiliser les GameObjects et MonoBehaviour ensemble.

Nous voulions également garder la logique de jeu dans les GameObjects et les MonoBehaviours car ils facilitent vraiment le prototypage – cette configuration vous permet de rassembler des éléments et d'écrire des scripts, de télécharger des scripts sur Internet ou d'utiliser des packages de Asset Store pour le prototypage. Nous voulions cette itération rapide et cette liberté, mais nous aimions aussi que Netcode for Entities nous offre une couche réseau performante. Je l'avais déjà utilisé sur quelques projets clients et projets de recherche personnels, donc je savais que son niveau de qualité pouvait soutenir le niveau de gameplay que nous voulions.

Lorsque nous avons commencé, il y a environ trois ans, Netcode for GameObjects existait, mais il manquait encore quelques fonctionnalités que nous voulions, en particulier la prédiction côté client. Avec la prédiction côté client, s'il y a un retard entre le serveur et le client, le client prédit ce que le serveur va faire et le fait instantanément – donc les contrôles des joueurs semblent réactifs même en cas de retard. Vous n'avez pas à attendre que le serveur vous dise qu'un joueur a bougé ou quoi que ce soit – vous le faites déjà. C'est quelque chose que Netcode for Entities avait dès le départ.

Pour le prototypage, nous avons essentiellement pris un projet que nous avions déjà et avons plongé dedans. Nous avons commencé par des choses simples – ramasser des objets, abattre des arbres – et progressivement, nous avons commencé à développer ce que serait une partie du gameplay. Nous étions encore en phase de prototypage, donc nous ne nous inquiétions pas trop de la qualité du code. Nous essayions de trouver le plaisir et de regarder nos piliers de jeu, y compris "la survie pour tous." Nous voulions un jeu de survie, mais nous ne voulions pas qu'il soit super difficile ou punitif - nous essayions de distiller ce qui est vraiment amusant et excitant dans ce genre.

Nous nous sommes demandé : Qu'est-ce que les gens aiment dans l'artisanat et la collecte de ressources ? Qu'est-ce qui ne les intéresse pas ? Cela nous a aidés à définir comment les joueurs obtiennent des ressources, comment ils les déplacent d'un endroit à un autre, comment ils font de l'artisanat. Nous avons compris tout cela en prototypant et en itérant assez rapidement en utilisant des GameObjects et des MonoBehaviours.

Parce que nous avons commencé par cette petite démo de preuve de concept, nous pouvions nous connecter par adresse Internet, dès le départ. Il était possible de se connecter en utilisant une IP d'ordinateur, mais nous avons également utilisé le service Relay de Unity, qui vous permet d'héberger un jeu sur un serveur Relay dans le cloud. Avec Relay, tout le monde peut rejoindre ce jeu en utilisant un code de connexion, et les gens peuvent se connecter depuis chez eux ou au bureau sans VPN ni IP connue. Cela signifiait que nous pouvions entrer dans un rythme de tests de jeu hebdomadaires - et nous les faisions au travail et sur nos réseaux domestiques, ce qui nous a permis de tester notre architecture réseau en parallèle avec le gameplay avec toutes sortes de vitesses de connexion différentes. À la fin, nous avons gardé Relay en production.

Nous avons essayé de rester aussi proches que possible des packages publiés. Si nous trouvions un bug dans l'un des packages, nous l'identifierions, apporterions le package localement et essaierions de le corriger. Parfois, nous allions sur Slack après et envoyions un message à l'équipe Netcode de Unity pour expliquer le problème et notre correction afin qu'ils puissent le prendre et faire les PR - et parfois l'intégrer dans la version finale. Nous n'étions pas nécessairement impliqués dans la correction, mais en travaillant dans un environnement de production, nous avons trouvé certains problèmes qu'ils n'avaient pas encore (bien que parfois ils aient déjà eu une meilleure correction que ce que nous avions proposé, ou ils nous disaient que nous l'utilisions mal).

Parce que nous avons développé de cette manière, à distance via Relay, nous n'avons pas ajouté de mode hors ligne avant plus tard, près de la sortie. Le mode hors ligne n'ouvre aucun socket réseau, et il utilise quelque chose appelé un pilote en processus. Il se comporte effectivement comme s'il s'agissait d'un réseau, avec un serveur et un client, mais ils s'exécutent dans le même processus et communiquent entre eux. Au lieu de l'envoyer à travers le réseau, ils l'envoient directement au client. On l'appelle une connexion en cours de traitement, et c'est très rapide car vous n'avez pas à attendre que des octets réels traversent le réseau, mais cela passe par tout le même flux que notre gameplay.

En travaillant de cette manière, nous n'avions pas besoin de coder une version différente – c'est notre mode solo et notre mode multijoueur. Le mode solo et hors ligne est toujours un jeu en réseau, c'est juste que nous n'utilisons pas le réseau – tout se passe en interne.

Cela signifiait essentiellement que nous avions une architecture de code que nous pouvions utiliser partout. Le coût de cela, cependant, est que lorsque vous hébergez ou êtes en mode solo, vous simulez le serveur et le client, créant un défi de performance pour faire fonctionner les deux en même temps. Avec des serveurs dédiés, un serveur peut aller vivre dans une ferme de serveurs quelque part, donc tout ce dont vous avez besoin est ce qu'on appelle le client, qui rend tout joli et répond à ce que le serveur communique. Mais en mode solo, puisque nous simulons, le jeu doit faire les deux et ne peut pas simplement rester sur un serveur dédié quelque part.

Cela s'est avéré être l'un de nos plus grands défis de performance, en optimisant pour que le serveur et le client puissent se trouver dans le même jeu, dans le même cadre, et atteindre notre objectif de 60 images par seconde à une bonne résolution. Cet objectif était vraiment important pour nous.

Découvrez les autres volets de notre série de blogs approfondis sur Survival Kids production:
- "Conseils sur les graphismes et le rendu de Survival Kids"
- "Mise en page des niveaux et flux de travail de terrain dans Survival Kids"

Restez à l'écoute pour le quatrième et dernier article de la série, partie 2 de notre histoire multijoueur, qui explore comment nous avons développé cette architecture réseau pour permettre le jeu en écran partagé et le partage de jeux sur Nintendo Switch 2.

Pour en savoir plus sur les projets réalisés avec Unity, visitez la page Ressources.