Essayez de garder cela aussi simple que possible et les interfaces bien définies et documentées. La maintenance et le débogage d'un système complexe en production se transforment facilement en enfer. Donc, s'il existe une approche simple et complexe, réfléchissez-y à deux fois avant de vous lancer dans l'approche complexe.
Définition des services
Je pense que la première étape consiste à identifier les services et leurs dépendances : contenu statique, authentification, chat local, canaux de chat global, canaux de chat régionaux, liste d'amis, guildes, sac / inventaire, salle des ventes, carte globale, monde, ...
Ensuite, pour chacun de ces services, il a été décidé si le client pouvait leur parler directement. Par exemple, il est assez facile de laisser le client parler directement avec les serveurs responsables des canaux de discussion globaux. Les serveurs mondiaux n'ont pas du tout besoin d'être impliqués dans les messages de chat. Le chat régional peut être implémenté de la même manière, mais les serveurs mondiaux doivent avertir les serveurs de chat lorsque les joueurs changent de région. Encore une fois, ils n'ont pas à se soucier des messages.
La troisième étape consiste à penser à l'équilibrage de charge au sein d'un service . Par exemple, les canaux de discussion mondiaux et régionaux peuvent être répartis sur plusieurs serveurs en fonction de leur nom. C'est probablement une bonne idée de ne pas coder en dur cette division dans le client, mais de fournir un service de recherche.
Serveurs du monde
La partie la plus difficile est généralement les serveurs mondiaux , donc je commence par une approche simple. C'est probablement une bonne idée de laisser le client parler directement au serveur responsable de la région dans laquelle il se trouve. Ainsi, lors de la connexion ou de la région traversée, le client doit être informé du serveur auquel se connecter.
L'approche simple consiste à diviser le monde en régions indépendantes . Avec des régions indépendantes, je veux dire qu'un joueur ne peut pas regarder d'une partie à une autre et que les monstres ne peuvent pas traverser de parties. Ces régions sont différentes des régions que les joueurs voient en fonction du paysage et de l'histoire du monde extérieur. Habituellement, la plupart des monstres sont dans des donjons et les joueurs ont tendance à accepter qu'ils doivent passer par une passerelle pour entrer dans un donjon. Surtout si ces donjons sont instanciés par groupe de joueurs. D'autres exemples sur le monde extérieur sont différents continents et vallées entourées de hautes montagnes.
Une approche mondiale continue devient très rapidement complexe, il est donc logique de bien la planifier: de quelles informations le client a-t-il besoin? Quelles informations les serveurs doivent-ils partager? Le joueur n'interagira principalement qu'avec les objets (y compris les monstres et les PNJ) de la même région. Vous pouvez tricher en plaçant des objets hors de portée de clic à partir de la bordure de la zone. Cela signifie que le client est principalement intéressé par la lecture seule des informations pour les zones voisines. Dans ces cas, les serveurs de zone n'ont rien à coordonner, sauf pour vérifier l'autorisation que le joueur est suffisamment proche pour se connecter à une zone voisine.
Cela ne laisse qu'un très petit nombre de cas difficiles dans lesquels des objets ou des actions doivent traverser une frontière de serveur. Ce qui est une bonne chose car ces cas tels que les flèches et les sorts sont critiques pour les performances. Il peut être judicieux de diviser le combat en attaque et en défense. Ainsi, le serveur d'un lanceur de sorts définira les paramètres d'attaque, y compris la position du lanceur de sorts. Le serveur du défenseur recevra le message de l'attaque et calculera l'impact. Le serveur de l'attaquant n'a pas besoin de connaître l'impact; le client l'apprendra en utilisant sa connexion en lecture seule.
Selon la complexité de votre modèle de lecteur, le transfert vers un autre serveur peut prendre quelques secondes (Second Life a un énorme problème avec cela). Le problème peut être atténué en préparant le transfert à l'avance lorsque le joueur se rapproche d'une frontière virtuelle. De sorte que la plupart des données du lecteur sont déjà mises en cache sur le serveur de destination lorsque le transfert réel se produit.
Sommaire
Divisez le problème en définissant différents services qui peuvent être répartis sur plusieurs serveurs avec peu de dépendances. Au cours de la prochaine étape, examinez la façon d'équilibrer la charge au sein des services critiques. Déléguez le travail d'équilibrage au client en lui demandant de se connecter directement aux serveurs concernés (les serveurs doivent évidemment vérifier les autorisations). Restez aussi simple que possible, documentez bien les responsabilités des différents services et serveurs, offrez l'option d'activer la sortie de débogage.
PS: Certaines de ces techniques peuvent être utilisées pour améliorer la fiabilité. Et vous devez garder cela à l'esprit car l'utilisation de nombreux serveurs implique un risque beaucoup plus élevé de rupture des choses; non seulement au niveau du logiciel mais également au niveau du matériel.