AVERTISSEMENT : Les réponses délivrées par Chad McKinney dans cette publication peuvent être assez techniques et velues, invoquant des termes propres à l’architecture serveur de CIG.
Question par unobtanium
Chaque serveur du jeu a-t-il sa propre instance iCache qui copiera partiellement des sections du service de base de données globale pour un accès rapide ?
Je pensais que l’iCache allait être un service de base de données transversal auquel tous les serveurs de jeux pourraient accéder. D’après le récent épisode de Calling All Devs, il semble que chaque serveur de jeu aura plutôt sa propre instance d’iCache sur son disque, pour accélérer la vitesse de lecture/écriture de la base de données. Chaque instance iCache répliquerait les données pertinentes de la principale base de données globale, en fonction des sections de l’univers du jeu qui sont chargées sur ce serveur. Les “serveurs interconnectés” accèderont-ils à la base de données des autres pour obtenir les données ou échangeront-ils constamment des données pertinentes directement entre eux ?
Réponse par Chad McKinney
L’iCache est une batterie de services qui sont, comme vous le dites, transversaux, qui peuvent être dynamiquement mis à niveau en fonction des besoins, et leur nombre est entièrement dissocié des instances de serveurs spécifiques. Les serveurs n’ont pas leurs propres bases de données, mais les “shards”[1] (dans notre usage, il s’agit d’une collection de serveurs dans un maillage travaillant ensemble) auront leurs propres registres, et les items et la base de données variable pour ces “shards” seront effectivement séparés les uns des autres puisque pour la plupart des “shards” n’interagissent pas les uns avec les autres (sauf dans cas où les joueurs se déplaçent entre les “shards” entre les sessions).
Je pense qu’une chose qui a peut-être été légèrement perdue dans le montage de l’épisode est que nous ne passerons pas immédiatement sur un “shard” unique mondial, mais que ce sera plutôt un processus progressif. Une fois que nous aurons introduit le Server Meshing, les mailles ne seront pas aussi larges et denses que nos objectifs de “shards” de taille régionale et peut-être même d’un groupe global unique. Au lieu de cela, ils agiront un peu comme nos instances de serveur, mais en nous permettant d’augmenter le nombre de joueurs à partir de 50. Au fur et à mesure que nous testons, apportons des améliorations, optimisons, corrigeons des bugs, etc., nous pourrons augmenter le nombre de joueurs pour atteindre les objectifs plus importants que nous visons, mais ce ne sera pas dès le premier jour.
Les “serveurs interconnectés” accèderont-ils à la base de données des autres pour obtenir les données ou échangeront-ils constamment des données pertinentes directement entre eux ?
Les serveurs d’un maillage communiqueront entre eux en permanence, de la même manière que les clients et les serveurs communiquent entre eux en permanence, mais les requêtes basées sur la persistance iront à l’iCache, et non aux autres serveurs du maillage.
Question par DankFudge
Merci pour ces informations supplémentaires ! À votre avis, à quoi ressemblerait la mise en œuvre de la 1ère itération de tout cela ?
Le “shard” comprendra-t-il l’ensemble de Stanton ? Combien de serveurs un “shard” contiendrait-il dans le Tier 0 ? Si les “shards” ne communiquent pas entre eux, comment la persistance fonctionnera-t-elle lorsque je me déconnecterai et que je reviendrai dans un autre “shard” ?
Réponse par Chad McKinney
Les registres de persistance des “shards” sont séparés, de sorte que leur vision du monde soit dissociée. C’est là où je voulais en venir lorsque j’ai mentionné l’univers du jeu dans la vidéo, mais au montage, cela s’avère ne pas avoir le sens que j’avais prévu. Le but est d’obtenir une densité de joueurs aussi élevée que possible afin que les joueurs jouent SC en un seul “shard”. Il se peut qu’ils n’aillent jamais dans un “shard” en Europe ou en Asie (suivant comment fonctionneront les “shards” basés sur la région, juste des exemples au hasard) mais du point de vue de ce joueur, ils auront une vision cohérente du monde, et de leurs amis, aussi longtemps qu’ils joueront dans la même région (et avant d’avoir des “shards” basés sur la région, nous pouvons utiliser des techniques de matchmaking pour obtenir un effet similaire).
Question par Ash
Ce qui me bloque un peu, c’est la persistance totale ; le langage utilisé dans le CAD (Calling All Devs) m’a fait comprendre que la persistance totale nécessite le Server Meshing, mais nous avons déjà la persistance dans les vaisseaux, les habitations et quelques autres endroits. Il me semblait que l’iCache, le Server Meshing et la persistance avaient tous besoin les uns des autres, mais alors iCache et la Persistance existe déjà ?
C’était un peu déroutant, pourriez-vous expliquer ça un peu mieux ?
Réponse par Chad McKinney
Dans un certain sens, ils exigent tous les uns des autres de travailler dans la version finale qui nous est destinée, c’est pourquoi il peut être parfois déroutant d’expliquer, car nous devons expliquer la vision finale du système, et décomposer simultanément la manière dont nous introduisons des segments du système entier actuellement, de telle sorte qu’ils puissent fonctionner sans le reste. En bref, l’objectif est le Server Meshing, mais pour cela, nous avons besoin à la fois d’une persistance globale et d’un iCache. iCache ne nécessite pas techniquement de Server Meshing, mais vous n’avez pas tout à fait tort quand vous dites qu’il y a un rapport avec le fait qu’il nécessite un concept de “shard” pour commencer. L’idée est de traiter efficacement les instances d’un seul serveur comme un maillage de nœuds de serveur unique pour commencer. La persistance globale est actuellement en vigueur, en ce sens que l’état global du monde est persistant, mais seulement par instance de serveur, et seulement dans la mémoire interne (non stockée dans une base de données). Avec iCache, nous commençons par déplacer cette persistance basée sur les instances de serveur hors de la mémoire du serveur, dans une base de données appropriée où elle sera analysée en fonction des “shards” (comme je l’ai mentionné ci-dessus). Et comme je l’ai dit, tantque le Server Meshing ne fonctionnera pas totalement, cela signifiera que chaque instance de serveur est un maillage de serveur unique. Ce qui signifie qu’elle aura également son propre registre de persistance dans les “shards”. Une fois le Server Meshing mis en place, les “shards” augmenteront la densité du serveur (d’abord statiquement, puis dynamiquement) et les choses commenceront à ressembler à notre objectif final. C’est comme construire une échelle tout en la gravissant simultanément.