Jump to content
Maarkreidi

Ask a dev : un supplément d’ICache

Recommended Posts

Le show Ask a Dev du vendredi 28 août était riche en infos mais Chad-CIG était tellement emballé par son travail qu'il passait parfois d'un sujet à l'autre en omettant que nous ne sommes pas des experts en la matière. Sans oublier que certaines parties ont été coupées au montage. Comme certaines choses sont encore un peu confuses, certains ont demandé des éclaircissements sur le sujet. Chad qui n'est pas avare en explications est encore une fois allé répondre aux backers sur Spectrum.

Bonne lectrure

 

Chaque serveur de 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 qu'iCache allait être un service de base de données à échelle horizontale 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 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 mondiale en fonction des sections de l'univers du jeu qui sont chargées sur ce serveur. Les serveurs maillés accèderont-ils à la base de données des autres pour accéder aux données ou échangeront-ils constamment des données pertinentes directement entre eux ?


Chad McKinney

ICache est une flotte de services qui sont, comme vous le dites, à l'échelle horizontale, qui peuvent être dynamiquement mis à niveau en fonction des besoins, et leur nombre est entièrement découplé des instances de serveurs spécifiques. Les serveurs n'ont pas leurs propres bases de données, mais les Shards (dans notre usage, il s'agit d'une collection de serveurs dans un maillage travaillant ensemble) auront leurs propres enregistrements, et les éléments et la base de données variable pour ces Shards seront effectivement séparés les uns des autres puisque pour la plupart les Shards n'interagissent pas les uns avec les autres (avec le cas de figure des joueurs se déplaçant entre les Shards entre les sessions).

Je pense qu'une chose que nous avons peut-être un peu oubliée lors du montage de l'épisode est que nous ne passerons pas immédiatement à un shard global unique, mais qu'il s'agira plutôt d'un processus progressif. Une fois que nous aurons introduit le maillage, les mailles ne seront plus aussi larges et denses que nos objectifs de shards de taille régionale et peut-être même d'un shard 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 le premier jour.

Citation

Les serveurs maillés accèderont-ils à la base de données des autres pour accéder aux données ou échanger constamment des données pertinentes directement entre eux ?

Les serveurs d'un réseau maillé 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 à un autre serveur


Comment la mise en œuvre de tout cela au niveau 0 se présenterait-elle à votre avis ?
Le shard comprendra-t-il l'ensemble de Stanton ? Combien de serveurs un shard contiendrait-il dans le Tier 0 ? Si les tessons ne communiquent pas entre eux, comment la persistance fonctionnera-t-elle lorsque je me déconnecterai et que je reviendrai dans un autre shard ?

Chad McKinney


Les registres de persistance de Shard sont séparés, de sorte que leur vision du monde est découplée. C'est là où je voulais en venir lorsque j'ai mentionné les lignes du monde dans la vidéo, mais elles ont été couplées pour 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 toute leur expérience de jeu avec SC en un seul shard. Il se peut qu'ils n'aillent jamais dans un shard en Europe ou en Asie (à savoir comment les shards régionaux fonctionneront, mais ce ne sont que des exemples aléatoires), mais du point de vue du joueur, ils auront une vision cohérente du monde, et leurs amis aussi, tant qu'ils joueront dans la même région (et avant d'avoir des shards régionaux, nous pouvons utiliser des techniques de match making pour obtenir un effet similaire).


La chose sur laquelle je suis un peu bloqué, c'est sur la persistance totale. Vendredi, le langage du CAD m'a fait comprendre que la persistance totale nécessite un maillage, mais nous avons déjà la persistance dans les vaisseaux et les habs et quelques autres endroits. Il me semblait qu'iCache, le Maillage et la Persistance avaient tous besoin les uns des autres, mais alors iCache et la Persistance existaient déjà ?
C'était un peu confus, pouvez-vous éclaircir ce point ?


Chad McKinney


Dans un certain sens, ils exigent tous les uns des autres de travailler dans la version finale qui est prévue, c'est pourquoi il peut être parfois déroutant d'expliquer, car nous devons à la fois expliquer la vision finale du système et décomposer simultanément la manière dont nous introduisons des segments du système entier de telle sorte qu'ils puissent fonctionner sans le reste du système. En bref, l'objectif est le maillage des serveurs, mais pour cela, nous avons besoin à la fois d'une persistance globale et d'un icache. Icache ne nécessite pas techniquement de maillage de serveur, mais vous n'avez pas tout à fait tort de penser qu'il y a un rapport avec le fait qu'il nécessite un concept de shard pour commencer. La manière dont cela fonctionne est de traiter efficacement les instances d'un seul serveur comme un maillage de nœud 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 et 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, avant que le maillage des serveurs ne fonctionne, cela signifie que chaque instance de serveur est un maillage de serveur unique, ce qui signifie qu'elle aura également son propre enregistrement de persistance des shards. Une fois le maillage du serveur mis en place, les shards augmenteront la densité du serveur (d'abord statiquement, puis dynamiquement) et les choses commenceront à ressembler à notre objectif final, jusqu'à ce qu'il y ait une série d'étapes progressives et un travail temporaire pour nous soutenir. C'est comme construire une échelle tout en la gravissant simultanément.

 

Trad : @Maarkreidi SwissStarshipq.org

zbwfBnp.gif

"... there are a lot of Freelancer fans out there that love that, that mouse control where guns target for you but noit’s going to be Wing Commander"

source: http://tinyurl.com/q46br4w

Link to post
Share on other sites

×
×
  • Créer...