Comment Multiplayer a pris le large avec Ship of Fools, le succès du peer-to-peer multijoueur de Multiplayer.

Lorsque Fika Productions a cherché à combler le manque d'un jeu de roguelite en coopération sur le marché, son objectif était la coopération sur canapé. Et puis 2020 est arrivé. Nous nous sommes entretenus avec Daniel Carmichael, principal programmeur du jeu, et Yannick Vanderloo, développeur, pour discuter de leur jeu et explorer certains des défis de développement qu'ils ont dû relever pour mettre Ship of Fools sur le marché à une époque compliquée pour l'industrie.

Quelle a été l'inspiration à l'origine de Ship of Fools? Avez-vous des collègues ayant une formation nautique ?

Daniel : Notre inspiration a d'abord et avant tout été de combler le manque de marché pour un roguelight coopératif. Nous sommes tous des fans du genre roguelite, et bien qu'il y ait beaucoup de jeux roguelite excellents, nous avions l'impression qu'aucun d'entre eux ne faisait vraiment bien la partie coopérative.

Sur le plan thématique, nous aimions l'idée d'un bateau, car si le bateau coule, tout le monde coule. C'est l'idée principale : travailler ensemble pour maintenir le bateau à flot. Personne n'avait d'expérience nautique, et nous ne sommes pas des créatures marines ou quoi que ce soit de ce genre.

Aucun poulpe ou chien de mer salé ne fait partie du personnel. Je l'ai. À quoi ressemble une étude de marché pour vous ?

Daniel : Notre étude de marché n'était en fait qu'une petite activité de recherche sur le Reddit, mais nous en avons retiré beaucoup. Sur 25-30 subreddits consacrés aux coopératives et aux roguelites, nous avons posé la question suivante : "Qu'est-ce qui est nécessaire, selon vous, pour qu'un jeu de roguelite en coopération soit un succès ?" Nous avons reçu de nombreuses suggestions, les avons résumées dans un document et avons cherché des recoupements et des thèmes. Ce processus a validé certaines de nos idées et nous en a donné de nouvelles.

Quel a été votre moment préféré dans le cadre du projet Ship of Fools?

Daniel : Nous avions un petit gag au bureau. À chaque fois que nous proposions une petite fonctionnalité, quelqu'un disait : "Nous avons un jeu !". Un jour, nous avons fusionné une grande partie du jeu qui était vraiment importante, je l'ai testée et je me souviendrai toujours d'avoir dit à l'équipe : "Nous avons un jeu vendable! C'était un moment de grande fierté pour nous.

Y a-t-il eu un aspect particulièrement difficile dans le développement du Multiplayer du jeu, et comment l'avez-vous surmonté ?

Yannick : La mise en réseau dans les jeux est généralement simple lorsque l'hôte ou le client prend le contrôle total. Toutefois, les choses se compliquent lorsque le contrôle doit être divisé, par exemple lorsque certains éléments sont gérés par le joueur local et d'autres par l'hôte du jeu.

Les projectiles ont été particulièrement difficiles à utiliser dans cette configuration. Nous voulions qu'ils soient percutants lorsqu'ils sont tirés, ce qui impliquait de prendre en compte de nombreux scénarios. De plus, lorsqu'un ennemi riposte et qu'un joueur dévie le tir, nous avons dû planifier méticuleusement les interactions et nous assurer qu'elles convenaient à tous les joueurs, même dans des situations de latence élevée. Il y avait beaucoup de cas limites à prendre en compte. En particulier, comment le rendre rapide et réactif pour les deux joueurs.

Daniel : Nous avons également rencontré un autre problème de taille, celui de la mise en réseau. Nous avons passé un bon an et demi à concevoir le jeu pour la coopération locale, sans même penser au jeu en ligne. Puis bam ! La pandémie a frappé. Soudain, notre jeu exclusivement local n'avait plus beaucoup de sens puisque tout le monde était coincé à la maison, sans se retrouver ensemble.

À l'origine, nous étions très attachés au face-à-face, à l'instant présent. C'était le cœur de notre jeu. Mais avec la pandémie, notre éditeur nous a dit : "Hé, il faut qu'on se mette en ligne", et nous nous sommes dit : "D'accord, faisons-le". Nous avons eu l'impression de devoir retravailler toute une année pour adapter chaque partie du jeu au jeu en ligne.

Alors, un petit conseil pour les autres développeurs : pensez toujours au jeu en ligne dès le départ, même si vous n'êtes pas à 100 % sur le sujet. Concevoir en pensant à l'Internet est généralement une bonne chose, et il est beaucoup plus facile de l'éliminer plus tard que de l'intégrer après coup.

Parlez-moi de la gestion des projectiles, et comment Netcode for GameObjects est-il entré en jeu ici ?

Yannick : La mise en réseau de notre jeu a pris une tournure unique. Nous n'avons pas de Netcode for GameObjects traditionnel. Au lieu de cela, nous avons des objets qui existent à la fois du côté du client et du côté de l'hôte, chacun étant conscient des actions de l'autre et sachant qui a le contrôle à tout moment. C'est comme s'ils étaient constamment en train de discuter, de s'informer mutuellement de ce qui se passe.

Par exemple, dans un scénario où une balle est tirée, si elle atteint la cible du côté de l'hôte, le jeu attend que le client confirme l'atteinte. Le client peut être d'accord ou dire : "Non, je l'ai évité" ou même "J'ai réfléchi à la balle". En fonction de la réponse du client, le jeu ajuste le résultat, en veillant à ce que les deux parties soient en phase.

Cette configuration permet une grande flexibilité. Les joueurs du côté client peuvent voir des réactions immédiates à leurs actions, comme une balle déviée, ce qui donne au jeu une impression de réactivité. Toutefois, le résultat final peut nécessiter des ajustements en fonction de la contribution de l'hôte, qui peut annuler les réactions initiales en cas de divergence.

Il s'agit d'une sorte de danse, l'autorité pouvant passer d'un côté à l'autre. Nous avons trouvé que la solution la plus simple consistait à laisser chaque partie faire ce qu'elle avait à faire, puis à réconcilier les différences au fur et à mesure qu'elles apparaissaient, sur la base du retour d'information de l'autre partie. Il s'agit d'un processus de collaboration, qui garantit que l'hôte et le client contribuent tous deux au déroulement du jeu.

Voici une explication visuelle pour vos lecteurs.

Dans la première image, nous avons notre configuration Multiplayer, où je joue le rôle de Todd, l'hôte à gauche, et mon ami est Hink, le client à droite.

Ensuite, un ennemi de type crabe apparaît et lance un projectile. Il s'agit ici d'une question de coordination : l'hôte et le client sont tous deux informés par le biais d'un appel de procédure à distance. Les deux joueurs voient le projectile, mais le fait qu'il touche le bateau ou qu'il soit dévié dépend des réactions des joueurs, et l'hôte doit attendre l'entrée du client pour confirmer le résultat final.

Enfin, nous voyons ici ce qui se passe lorsque le client, qui joue le rôle de Hink, dévie le projectile. Il y a un peu de retard en cas de ping élevé, de sorte que si l'hôte voit d'abord le projectile frapper le bateau, il se corrige de lui-même une fois que la réaction du client est confirmée. Ainsi, le client ne ressent aucun décalage - c'est comme s'il jouait en temps réel, et ses actions sont reflétées par l'hôte pour maintenir la synchronisation du jeu.

L'idée est de s'assurer que lorsque vous êtes dans le feu de l'action, en train de tirer ou de repousser une attaque, le jeu réagit instantanément, ce qui donne une impression de fluidité à l'expérience Multiplayer.

Avez-vous d'autres détails à nous communiquer ? Y a-t-il quelque chose que nos lecteurs pourraient retenir comme une leçon importante ?

Daniel : Nous avons relevé un certain nombre de défis, mais l'un des plus importants concernait la gestion de la mémoire. Nous avons dû apprendre à maîtriser l'assemblage et les Addressables, d'autant plus qu'il s'agissait du premier jeu Multiplayer pour l'ensemble de l'équipe.

Ce qui est amusant, c'est que notre jeu n'est même pas aussi riche en ressources, mais les temps de chargement ont atteint deux minutes à un moment donné, ce qui est fou pour un petit jeu. Cette décision a suscité la colère des joueurs.

Nous avons donc appris à nos dépens à rationaliser les choses, la mémoire et les actifs. Nous aurions dû définir les principes de base dès le départ.

Qu'en est-il des Addressables ? Qu'y avez-vous appris en particulier ?

Yannick : L'affaire avec Addressables est assez simple. Vous devez organiser vos actifs en groupes qu'il est logique de charger ensemble en même temps. De cette façon, vous n'encombrez pas votre jeu avec des éléments que vous n'utilisez même pas dans une scène particulière.

Par exemple, notre jeu comporte différents secteurs, chacun ayant son propre ensemble d'ennemis, de scènes et de décors. Au départ, nous avons tout regroupé en un seul groupe massif, ce qui était un cauchemar pour les temps de chargement. Dans un souci de rationalisation, nous avons commencé à regrouper les actifs par secteur. Cela a fait une énorme différence car maintenant, nous pouvons charger seulement les ennemis ou seulement le décor d'un secteur selon les besoins, ce qui rend le tout beaucoup plus efficace et plus fluide au final.

Pourquoi avez-vous choisi Netcode for GameObjects (NGO) pour la mise en réseau ?

Yannick : Nous avons choisi NGO pour la mise en réseau, principalement parce qu'elle est soutenue par Unity. Cela signifie qu'il est susceptible d'évoluer en même temps que la plateforme et de bénéficier d'un soutien à long terme, ce qui est essentiel pour nous. De plus, NGO disposait de toutes les fonctionnalités dont nous avions besoin.

Nous voulions avant tout une connexion peer-to-peer pour éviter les coûts de serveur, ce qui peut s'avérer important pour un jeu dont les ventes futures et la base de joueurs sont incertaines. Avec NGO, nous avons eu la certitude de faire un pari sûr à la fois pour nos besoins actuels et pour notre développement futur. Cela semblait être un choix judicieux pour rester dans l'écosystème Unity et assurer un support à long terme pour notre jeu.

Quelle est la prochaine étape pour Ship of Fools?

Jusqu'à présent, nous avons déployé deux grandes mises à jour, remplies de contenu frais, et lancé deux DLC, introduisant de nouveaux personnages pour mélanger les choses. Ces DLC sont totalement optionnels, ce qui donne aux joueurs plus de choix sans qu'ils se sentent exclus s'ils décident de ne pas les prendre. Ce qui est génial, c'est qu'il n'y a pas d'autre solution. Ces mises à jour majeures du contenu étaient prévues et, d'après ce que nous avons vu, les gens les ont vraiment appréciées.

Pour ce qui est de la suite, nous avons des projets, mais nous devons rester discrets pour l'instant. Cependant, lorsque nous serons prêts à dévoiler les futures mises à jour, vous serez certainement au courant.

Intéressé par le développement Multiplayer ? Explorez la section consacrée au multijoueur dans le rapport sur les jeux Unity de 2024 pour découvrir les points de vue de studios performants, des données fraîches sur les raisons pour lesquelles davantage de studios développent des jeux multijoueurs, et une multitude de conseils pour vous aider, vous et votre équipe, à garder une longueur d'avance.