Informations sur l'architecture transparente du serveur MMO

Je recherche n'importe quel matériel sur des serveurs MMO sans couture! J'ai quelques articles dans les livres "Massively Multiplayer Game Development" et "Game Programming Gems 5." Quelqu'un a-t-il de l'expérience sur ce sujet ou connaît-il des articles à ce sujet?

Je m'intéresse aux "vues de haut niveau" ainsi qu'aux implémentations. Cela pourrait devenir le sujet de ma thèse de maîtrise et j'aimerais savoir à quel point il est difficile d'écrire un tel système, avant de commencer réellement la thèse. Pour l'instant, je n'ai pas encore décidé quel langage utiliser, je pense à Java ou Scala. Erlang pourrait être un choix, mais je n'ai jamais travaillé avec ça.

Remarque: L'exigence de base serait le mouvement. Tout autre système de jeu est facultatif et donne un "crédit bonus".

Maintenant, pour ce que je veux dire avec "serveur transparent": je veux donc mettre en place un cluster de serveurs où chaque nœud contrôle une partie du monde du jeu, avec des limites statiques. Les joueurs peuvent désormais se déplacer d'un bout à l'autre du monde sans changer d'instance ni toucher un "téléporteur". Je pense que WoW fait ça. Dans mon back-end cependant, le joueur passe d'un serveur à l'autre.

La principale complexité de la gestion d'un tel système vient de la fluidité dont vous avez besoin. Comme l'a dit Josh, la résolution du problème de transfert d'une entité d'un serveur à un autre est un élément clé du package.

Ce n'est pas le seul problème cependant - si des entités sur plusieurs serveurs doivent interagir dans le cadre d'une opération, vous avez maintenant un problème de synchronisation où chaque système a besoin de données de l'autre côté pour continuer, mais au moment où les données arrivent, il peut déjà invalide. Vous pouvez essayer de résoudre ce problème en décomposant l'opération en plusieurs messages avec possibilité de restauration si un côté se retire, mais comme vous l'avez vu au chapitre 3.1 dans "Développement de jeux massivement multijoueurs", cela complique considérablement toute logique de jeu que vous devez faites cela avec. Scala et Erlang vous aident à obtenir le bon système de messagerie - ils ne vous aident pas à décomposer ce qui était auparavant une fonction à 10 lignes en de nombreux messages et états différents que vous devez maintenant suivre.

De toute évidence, ce problème n'est pas entièrement nouveau, et les bases de données relationnelles prennent en charge ce type de problème en stockant toutes les données de manière centralisée et en laissant plusieurs clients interroger et les modifier selon leurs besoins, en annulant les transactions si nécessaire. Cela vous donne la plupart de vos exigences de correction, mais impose malheureusement des problèmes de performances peu pratiques et rend la mise en œuvre de la logique de jeu difficile (car une grande partie de votre logique est maintenant écrite dans des procédures stockées de base de données). Un autre type de base de données pourrait fournir une bonne solution ici, surtout si vous êtes prêt à renoncer aux exigences de fiabilité que la plupart des SGBDR fournissent.

La plupart des jeux professionnels contournent ce problème en ne tentant même pas de le faire, en gardant la taille du fragment suffisamment petite pour mettre tous les joueurs sur un serveur, en divisant le monde en parties qui n'interagissent pas vraiment (voir l'exemple WoW dans les commentaires ci-dessus) , ou en distribuant le jeu sur plusieurs serveurs en fonction de la fonction plutôt que de la géographie (par exemple, tous les combats se déroulent sur un serveur, tous discutent sur un autre) afin qu'il n'y ait pas de «coutures» à affronter.

Je m'intéresse aux "vues de haut niveau" ainsi qu'aux implémentations.

Les implémentations sont généralement assez profondément impliquées et vous n'en verrez probablement pas beaucoup parler ici. Le logiciel StackExchange n'est pas bien adapté à ce genre de discussion impliquée, sans compter qu'il impliquerait un investissement important en temps de quelqu'un.

Je voudrais savoir combien il est difficile d'écrire un tel système

Pas plus ou moins dur que tout autre système: cela dépendra de vos besoins et des fonctionnalités que vous comptez piloter. Vous pouvez écrire des implémentations triviales trivialement, mais les choses non triviales seront bien sûr beaucoup plus difficiles. L'un des plus gros problèmes est que vous n'aurez probablement pas assez de clients réels pour savoir si votre système évolue réellement au niveau "massif" sur lequel WoW et les autres jeux fonctionnent.

Les MMO ne sont pas magiques. La plupart de leur technologie n'a rien de spécial lorsqu'elle est prise isolément, c'est simplement qu'un certain nombre de bits de technologie plus petits et plus simples sont combinés très intelligemment pour permettre des simulations parallèles connectées à plus grande échelle d'un état mondial partagé.

Je veux donc mettre en place un cluster de serveurs où chaque nœud contrôle une partie du monde du jeu, avec des limites statiques. Les joueurs peuvent désormais se déplacer d'un bout à l'autre du monde sans changer d'instance ni toucher un "téléporteur".

Essentiellement, vous parlez de transfert de simulation. Cela peut être fait assez simplement et n'est pas nécessairement une technologie spécifique aux MMO (les jeux peer-to-peer ont tendance à supporter tous les mêmes mécanismes sous-jacents pour implémenter la migration des hôtes). La prémisse de base est que chaque serveur comprenne la topologie des serveurs "autour" (en particulier, un serveur pour le nœud mondial A doit connaître les serveurs pour les nœuds mondiaux adjacents à la simulation) ainsi que pour définir un tampon autour duquel vous envisagez une entité simulée particulière "proche" d'un serveur adjacent.

Lorsqu'une entité entre dans la mémoire tampon de «fermeture», vous commencez également à la signaler au serveur adjacent. Une fois que l'entité a franchi le seuil réel, vous envoyez un message au serveur adjacent avec l'état complet de l'entité et un message indiquant que le serveur adjacent doit reprendre l'entité. De toute évidence, vous voulez que cela soit aussi fiable que possible.