Pourquoi les MMORPG utilisent-ils toujours plusieurs serveurs?

Les MMORPG, certains MOBA comme League of Legends ou même StarCraft 2 vous obligent généralement à choisir un serveur. Habituellement, ce sont les États-Unis, l'UE et la MER, dans les MMORPG, beaucoup par emplacement. Je peux voir que cela était nécessaire il y a quelques années, mais maintenant avec l'avènement d'AWS et d'offres similaires qui vous permettent de faire évoluer de manière transparente votre "puissance du serveur", pourquoi y a-t-il encore des serveurs séparés?

Mon train de pensée est comme ceci (en utilisant Star Wars: The Old Republic comme exemple): - Vous êtes toujours sur une planète, une "instance" isolée des autres planètes. - S'il y a trop de gens sur une planète, SW: TOR crée une nouvelle instance du monde et y met des joueurs. - Si vous quittez le monde / changez d'instance, vous avez un écran de chargement

Alors pourquoi le jeu ne peut-il pas créer une instance pour cette planète. Cette instance (et seulement celle-ci) a vos données actuelles dans sa base de données et gère x joueurs. Dès que les joueurs x-50 sont sur cette instance, un nouveau serveur se déclenche et de nouvelles personnes apparaissent sur cette instance. Les 50 places sont réservées pour passer à votre groupe, etc.

Il pourrait y avoir une instance pour les trois régions principales pour maintenir la latence faible, mais cela vous permettrait de jouer avec d'autres joueurs de SEA, par exemple, si vous pouvez vivre avec un retard de 140 ms (ce qui n'est toujours rien à mon humble avis).

Chaque fois que vous changez d'instance ou voyagez dans un autre monde, votre serveur actuel transmet toutes vos données au serveur suivant, en vous assurant que vous n'avez pas besoin d'une grande base de données centralisée. Vous pouvez toujours en avoir un qui reçoit périodiquement des mises à jour à des fins d'analyse.

Lorsque vous vous déconnectez ou que les serveurs perdent la connexion, les données peuvent ensuite être transférées dans une énorme base de données optimisée pour le stockage des données. Les serveurs d'instance peuvent ensuite être optimisés pour un débit élevé.

Y a-t-il une raison particulière pour laquelle cela ne fonctionnera pas? Y a-t-il d'autres problèmes qui me manquent?

Les MMORPG, certains MOBA comme League of Legends ou même StarCraft 2 vous obligent généralement à choisir un serveur. Habituellement, ce sont les États-Unis, l'UE et la MER, dans les MMORPG, beaucoup par emplacement. Je peux voir que cela était nécessaire il y a quelques années, mais maintenant avec l'avènement d'AWS et d'offres similaires qui vous permettent de faire évoluer de manière transparente votre "puissance du serveur", pourquoi y a-t-il encore des serveurs séparés?

AWS n'est pas une solution aussi évidente qu'il n'y paraît. Cela peut être coûteux, dans certains cas davantage que l'utilisation de centres de données internes (pour un éditeur, le coût de ceux-ci peut être amorti sur plusieurs produits, par exemple). De plus, le stockage de fichiers binaires et de journaux sensibles sur du matériel hors de son contrôle pourrait poser problème. Enfin, la puissance de calcul réelle n'est pas toujours la raison de la ségrégation de la population "serveur" en MMO.

Mon train de pensée est comme ceci (en utilisant Star Wars: The Old Republic comme exemple): - Vous êtes toujours sur une planète, une "instance" isolée des autres planètes. - S'il y a trop de gens sur une planète, SW: TOR crée une nouvelle instance du monde et y met des joueurs. - Si vous quittez le monde / changez d'instance, vous avez un écran de chargement

Guild Wars 2, en fait, fait quelque chose de très similaire à cela. Les cartes sont simulées par des processus de serveur individuels et des instances de débordement sont créées selon les besoins en fonction du plafond de population de la carte et de certaines heuristiques pour les performances de la carte.

Guild Wars 2 possède deux grands centres de données, un aux États-Unis et un en Europe - il y a des échanges croisés entre ces centres de données (principalement pour les systèmes de poste de commerce et de commerce), mais en général, ils existent dans cette configuration, donc les joueurs de L'Allemagne, la France, et cetera n'ont pas à subir la latence plus élevée pour les serveurs de jeux américains. Au sein du centre de données, les joueurs sont classés en «mondes d'origine» (ou «éclats» en termes vernaculaires); mais l'une des raisons pour lesquelles cela est fait est de minimiser le nombre de joueurs qu'un client peut voir et doit lui signaler. L'aspect côté client de ce problème ne sera pas résolu en évoluant vers davantage de matériel serveur. L'explosion combinatoire côté serveur de chemins de rapport supplémentaires pourrait être,

Y a-t-il une raison particulière pour laquelle cela ne fonctionnera pas? Y a-t-il d'autres problèmes qui me manquent?

Vous manquez pas mal de choses, mais ce sont surtout des détails (et je n'expliquerai pas comment nous les traitons de toute façon, car ils sont considérés comme des secrets commerciaux) qui ne sont pas pertinents pour une question de haut niveau de type général. Je pense que le plus gros défaut de votre proposition est d'essayer de transmettre les données des joueurs au nouveau serveur lors du transfert d'un joueur. C'est un problème complexe qui n'évolue pas bien, il est probablement préférable dans la pratique d'avoir réellement les données de ce joueur sur un système centralisé de serveurs. C'est tout à fait faisable si vous n'utilisez pas ces bases de données et le magasin d'enregistrement d'exécution principal pour les données.

Il s'agit principalement de latence.

Tout d'abord, avoir un serveur géographiquement proche de chez vous réduit la latence. Si le serveur est à l'autre bout du monde, vous verrez plus de latence que si le serveur n'est qu'à quelques sauts.

Deuxièmement, les services comme AWS ne sont pas conçus pour le travail en temps réel. Ils sont conçus pour un débit élevé au détriment d'un peu de latence. Si votre page Web prend 250 ms de plus que d'habitude pour se charger en une seule fois, personne ne s'en soucie, mais si votre jeu prend 250 ms de plus que d'habitude pour traiter un message, le gameplay peut être sérieusement affecté. C'est pourquoi les MMO sont presque toujours hébergés sur du matériel dédié.

Mais c'est aussi une question de conception de jeux. Si vous donnez l'impression que tout le monde est dans le même monde mais que vous devez diviser une zone lorsqu'elle est trop pleine, les gens sont frustrés de ne pas pouvoir trouver leurs amis dans les lieux de réunion désignés. Ce genre de problème s'étendrait aux guildes, aux batailles PvP de masse, etc. Les joueurs sont habitués aux instances de nos jours mais il y a certaines zones qui devraient être partagées. Si vous avez des serveurs complètement séparés, au moins il n'y a pas de surprise ici.

Enfin, il y a d'autres problèmes technologiques à considérer. Même si chaque instance est assez isolée des autres, il existe généralement divers services qui doivent communiquer entre eux. La communication entre serveurs est difficile à bien faire dans les logiciels en temps réel et a conduit à divers exploits et bugs sur les MMO dans le passé. En particulier, la transmission de données de joueurs faisant autorité de l'un à l'autre est risquée. Par conséquent, les développeurs font souvent preuve de prudence et ont clairement délimité les frontières entre les serveurs, ce qui réduit la quantité de trafic qui doit les traverser.

en fait, je crois que la réponse n'est pas liée au réseau ou à l'architecture mais plutôt au jeu, généralement dans ce type de jeux, il y a des événements, et ces événements sont chronométrés selon les délais les plus confortables pour les personnes qui jouent sur le serveur, et c'est généralement liés au fuseau horaire où les gens vivent, d'où l'UE et les États-Unis, etc.

Une autre raison est de créer une séparation entre les mondes afin que s'il y a un groupe trop fort, il ne gâche pas le jeu pour tout le monde et que vous puissiez toujours vous déplacer dans un monde moins "difficile".

Du côté de la capacité du processeur du serveur, bien que les machines d'aujourd'hui soient assez solides, il y a toujours une limite à ce qu'une machine peut gérer, et donc créer une séparation entre les mondes est nécessaire pour protéger le jeu contre la surcharge et laisser les gens choisir le monde qu'ils veulent jouer pour qu'ils puissent jouer avec leurs amis. La mise à l'échelle horizontale ne consiste pas seulement à disposer de machines, vous avez besoin que votre application puisse fonctionner dans une architecture à l'échelle horizontale, et ce n'est pas si facile lorsque des milliers «d'actions» se déroulent simultanément avec une influence possible les unes sur les autres, et besoin de tout synchroniser. Je pense qu'il serait très difficile de le faire sur plusieurs machines.

Quel est le problème avec l'instanciation automatique? Lorsqu'un emplacement est trop peuplé, vous placez simplement les 1000 joueurs dans 10 instances différentes.

Le problème, c'est que les jeux en ligne concernent la communauté. Imaginez que vous avez organisé une réunion avec des personnes que vous avez rencontrées auparavant, et lorsque vous êtes tous là à un moment donné, vous ne vous voyez pas parce que vous êtes tous dans des cas différents? C'est ennuyeux et ça brise l'immersion.

Comment éviter cela? Cela pourrait être fait en plaçant chaque joueur dans la même instance à tout moment, de sorte que lorsque vous rencontrez un autre joueur une fois, vous pouvez être sûr de le rencontrer à nouveau lorsque vous êtes tous les deux au même endroit. Vous ne rencontrerez jamais les joueurs affectés à d'autres instances.

Mais que se passe-t-il lorsque vous voulez rencontrer quelqu'un de l'extérieur du jeu? Comme un ami réel que vous avez invité à jouer avec vous? Pour que cela se produise, vous auriez besoin de pouvoir choisir l'instance lors de la création de votre personnage. Comme à partir d'une liste d'instances avec des noms faciles à mémoriser. Malheureusement, le nom "instance" semble déroutant pour l'utilisateur moyen. Ils ne sont pas habitués à ce mot. Ne serait-il pas préférable d'utiliser un terme auquel ils sont habitués? Un terme comme ... Serveur ?