La pile Multiplayer derrière MMORPG Pantheon : Rise of the Fallen

Trouver son propre chemin est au cœur de l'expérience de jeu dansPanthéon : Rise of the Fallen : les joueurs peuvent aller n'importe où, escalader n'importe quoi, forger de nouvelles routes et suivre leur curiosité pour trouver l'aventure. Ce n'est pas si différent de la façon dont ses créateurs, Visionary Realms, abordent la création de ce MMORPG, ils le font à leur façon.

Transport des joueurs dans le monde fantastique de Terminus, Panthéon : Rise of the Fallen rappelle les MMO classiques, où la découverte accidentelle dans un monde ouvert et les interactions sociales avec les autres joueurs sont au cœur de l'expérience de jeu.

Créer n'importe quel jeu Multiplayer est un défi, mais un jeu en ligne hautement social à cette échelle est une quête épique. Nous nous sommes entretenus avec le programmeur en chef Kyle Olsen sur la façon dont l'équipe utilise Unity pour connecter les joueurs dans ce monde fantastique de MMORPG.

Ce qui fait Panthéon : Rise of the Fallen unique par rapport aux autres jeux MMO ?

C’est certainement l’aspect social.Il faut expérimenter le monde et le parcourir naturellement.Cela peut être un peu plus une ébauche, mais je pense que cela vous connecte plus à votre personnage, au jeu et au monde au lieu de simplement vous téléporter partout et rejoindre les systèmes de LFG ou simplement être placé dans un donjon. Vous apprenez un peu mieux la terre, vous devez naviguer et vous utilisez vos yeux plus que simplement rebondir comme un flipper d'objectif en objectif, en suivant des marqueurs de quête et tout. C'est plus un jeu de réflexion.

Comment gérez-vous la synchronisation entre l'expérience du joueur et des instances spécifiques du monde ?

Nous avons notre propre bibliothèque réseau conçue pour la couche de transport de sockets appelée ViNL. C'est le secret pour toutes les communications de zone, entre les zones et joueur à zone. Un serveur SQL dans le backend, un peu standard. Mais la plupart des transports sont gérés par notre propre bibliothèque réseau.

Comment abordez-vous le chargement des ressources pour ce monde géant ?

Nous avons une étape où nous précalculons nos continents dans ces tuiles, et nous avons différents backends que nous pouvons intégrer à cela. Nous en avons un qui ne sort que des prefabs standard, et nous en avons un qui sort des sous-scènes que nous utilisions avant Unity 6, puis nous avons des scènes Unity complètes que vous pouvez charger de façon additive, pour que vous puissiez choisir la façon dont vous voulez sortir votre contenu. Avant Unity 6, nous avions délaissé les prefabs et commencé à charger les sous-scènes de la DOTS et à utiliser cela, conçu sur BRG.

Nous disposons également d'une sortie qui peut également effectuer un rendu directement dans notre propre groupe de rendu par lots personnalisé, en utilisant simplement des objets programmables et en gérant nos propres données. Nous avons donc pu expérimenter et tester les différentes solutions et voir ce qui permet d'obtenir les meilleures performances client. Avant Unity 6, nous produisions et rendions l'ensemble du continent avec des sous-scènes, mais avec Unity 6, nous sommes en fait revenus à l'utilisation des prefabs avec Instantiate Async et Addressables pour tout gérer.

Nous utilisons le Resident Drawer et le GPU occlusion culling, qui ont fini par offrir de meilleures performances que les sous-scènes et notre propre groupe de rendu par lots. Je suppose que le GPU occlusion culling n'est tout simplement pas pris en charge par certains des autres chemins de rendu pour le moment. Nous avons donc rebondi pas mal, et nous avons atterri sur les Addressables pour gérer tout le chargement de la mémoire et des ressources, et les prefabs instantanés réguliers avec le GPU Resident Drawer semblent être les meilleures performances côté client pour le moment.

Avez-vous évolué vers Unity 6 pour tirer parti du GPU Resident Drawer ?

En fait, je le voulais vraiment pour le gommage d'occlusion. Je ne savais pas que seuls certains chemins de rendu utilisaient le gommage des occlusions. Nous essayions donc de l'utiliser avec le même rendu de sous-scènes qu'avant Unity 6 et nous nous rendions compte que rien n'était réellement gommé. Nous avons donc choisi de revenir à la sortie Prefab pour voir à quoi cela ressemblait avec le Resident Drawer, et FPS et gommage d'occlusion ont augmenté.

Nous avions quelques problèmes au départ, car Instantiate Async n'était pas disponible avant Unity 6, alors nous avions quelques blocages quand nous allions instancier nos tuiles. Il y a eu pas mal de choses qui ont été instanciées, mais en passant à Instanciate Async après correction de quelques bugs, nous nous sommes débarrassés du décrochage au chargement et la fréquence d'image globale était plus élevée après chargement, donc c'était juste gagnant-gagnant.

Y a-t-il eu des gains de productivité vraiment remarquables grâce au passage à Unity 6 ?

Tout ce dont j'ai parlé jusqu'à maintenant était tourné vers les clients, donc nos joueurs ont connu ces victoires. Pour les développeurs, la stabilité et les performances de l'Éditeur ont beaucoup augmenté. La stabilité de l'Éditeur dans Unity 6 a augmenté de façon assez substantielle. Il est très rare qu'un crash se produise actuellement. Rien que cela a été, du moins pour le côté du codage, une énorme victoire. Il semble plus stable dans son intégralité.

Comment gérer les modifications et les mises à jour sans tout interrompre ?

Nous créons avec des Addressables en utilisant très fortement les étiquettes, et nous réalisons l'emballage adressable par étiquettes. Ainsi, si nous modifions une zone spécifique ou une ressource dans une zone, ou comme un effet visuel associé à un sort ou autre, seuls les lots qui touchent cette étiquette sont mis à jour.

Et puis, notre propre système de diffusion de contenu, nous avons le jeu disponible sur Steam et notre propre correcteur, qui gèrent tous les deux les modifications delta, où nous ne faisons que publier de petites mises à jour via ces bundles adressables. Le netcode exige que la même version soit connectée en premier lieu, de sorte que le côté bibliothèque réseau est automatiquement géré dans le processus de poignée de main.

Quels conseils donneriez-vous à quelqu'un qui tente de s'attaquer à un jeu MMO ou à un autre projet Multiplayer ambitieux ?

Vous commencez petit, je suppose. C'est un processus étape par étape. Si vous êtes une petite équipe, vous commencez petit. C'est un processus étape par étape. Si vous êtes une petite équipe, vous ne pouvez pas trop mordre. Ce serait complètement accablant, mais c'est vrai pour tout jeu à plus grande échelle, pas seulement pour un MMO.

Sélection de la technologie probablement – faire des choix judicieux en amont et s'y tenir. Vous allez devoir vous battre avec beaucoup de middleware et de technologie backend pour bien travailler ensemble, et passer tout le temps au tout dernier truc cool ne sera pas de bon augure.

Quelle est la réalisation technique la plus passionnante pour votre équipe avec ce jeu ?

Je pense qu'il n'y a pas beaucoup de MMO en monde ouvert, point final, qui ont été créés dans Unity. Nous n'avons pas une énorme équipe, et nous créons un jeu qui est vraiment massif, donc nous devons nous concentrer sur les zones peu isolées, les développer du mieux que nous pouvons, puis passer à autre chose et obtenir des commentaires.

L'ensemble du package est assez nouveau. Quand il y a un MMO, il doit ressembler à un MMO dans l'esprit, avec beaucoup de gens autour, qui font leurs propres choses. Et nous y sommes parvenus – je pense que c’est le mieux que n’importe quel MMO Unity ait jamais eu. Je pense qu'on peut se taper dans le dos pour ça.

Obtenez plus d'informations de la part des développeurs sur la page Ressources Unity et ici sur le blog. Découvrez Panthéon : Rise of the Fallen en accès anticipé sur Steam.