Aller au contenu
  • Aider les non-techniciens à comprendre la technologie PES

    Published in 

    Aider les non-techniciens à comprendre la technologie PES

    Tout le monde entend parler de PES qui est attendu pour le prochain patch Alpha 3.18.0, mais savez-vous expliquer ce qu'est réellement PES ? Et savez-vous le 'expliquer aux des non-initiés ? 

    La tâche est ardue et je vois souvent des postes sur spectrum ou les gens soit ne comprennent pas PES soit en ont une vision tronquée car les explications sont trop techniques et dispersées dans de nombreuses sources officielles et à travers les différents médias utilisés par CIG. Un backer (Aaron_Rayne) a voulu corrigé ce manque de compréhension pour les gens moins techniques dans un post très imagé et simplifié. En voici la traduction car cet effort mérite d'être diffusé auprès du plus grand nombre possible à mon avis et surtout si vous ne comprenez pas ce qu'est PES.

    Bonne lecture

     

    source : https://robertsspaceindustries.com/spectrum/community/SC/forum/3/thread/helping-non-technical-people-understand-pes


    Préface

    Une discussion sur l'importance de revenir en arrière et de trouver une coupe sur une planète à un autre moment revient sans cesse. Ainsi, l'idée de PES est toujours expliquée et perdue dans cette allégorie de la tasse. La tasse ne sert qu'à démontrer la caractéristique ou la technologie de la persistance. L'idée n'est pas de cacher des gobelets à travers l'univers et de jouer à la chasse aux œufs de Pâques (bien que cela semble cool), de cacher un vaisseau et de donner des indices pour la chasse aux œufs de Pâques. L'idée est que les choses faites dans le jeu persistent, le meilleur exemple étant une épave. Si vous êtes abattu sur la planète, votre épave est là pour toujours. La plupart des gens vont dire "DUH", mais c'est pour ceux qui veulent comprendre, ou mieux comprendre.


     

    Mais comment faire pour que cela n'enlise pas le serveur ! Des milliers d'épaves sur des dizaines de planètes !

    Le serveur fait entrer et sortir l'environnement et les entités tout comme votre client fait entrer et sortir votre environnement autour de vous. Tout comme votre carte graphique élimine tout ce qui n'est pas visible sur votre écran. Ainsi, lorsque vous vous tournez d'un côté pour regarder des astéroïdes et que vous remarquez une baisse de 2 FPS, et que vous vous tournez à nouveau pour regarder dans l'espace profond, vos FPS augmentent. C'est ce qu'on appelle le "graphics culling". Pour ce qui est de l'environnement, c'est la beauté des conteneurs d'objets et du streaming qu'ils ont appelé le streaming de conteneurs d'objets côté client et le streaming de conteneurs d'objets côté serveur. Pour les zones d'atterrissage, elles ont été divisées en conteneurs prédéfinis, pour tout le reste, c'est basé sur la proximité. C'est ainsi que nous pouvons obtenir un énorme univers 1:1 presque en termes de jeu, sans écrans de chargement. Bientôt les vaisseaux auront des ocs, ce qui signifie que toutes les parties d'un vaisseau ne seront pas diffusées par le serveur ou par votre client. De meilleures performances dans les batailles. Il est là, mais pas tant que vous n'êtes pas dans cette section du vaisseau.


     

    Graph d'entités et couche de réplication

    CR a déclaré qu'ils ont dû passer de l'utilisation de leur icache à une base de données de graphes parce que l'icache était plus lent et qu'il n'était pas adapté à ce qu'ils pourraient vouloir à l'avenir. Par échelle, ils entendent se préparer à des millions ou des centaines de milliers d'utilisateurs simultanés plutôt qu'à quelques milliers. À partir de 2021, ils ont donc conçu une base de données de type graph qu'ils appellent en interne Entity Graph. Entity Graph est le nom de LEUR base de données graph. Je crois, sous réserve de correction, qu'elle est alimentée par Amazon Neptune (puisqu'ils utilisent Amazon Cloud et tout le reste, c'est logique puisque Neptune est extrêmement puissant, évolue et fait exactement ce qu'ils veulent. ) Si vous lisez la description d'Amazon Neptune, vous verrez des choses comme la réplication, la mise à l'échelle, des milliards de requêtes en millisecondes. Extrêmement rapide et soutenant des milliards de relations. En gros, toutes les bases de données graph devraient faire cela, mais il n'est pas impossible qu'ils utilisent Neptune. Des choses comme la sauvegarde/le snapshot sont des caractéristiques des bases de données graph et c'est pourquoi elles peuvent restaurer l'état d'un serveur après un crash avec tous les objets dynamiques non propriétaires là où ils étaient avant le crash.

     

    Couche de réplication

    La couche de réplication, dont les données proviennent du graphe d'entités (le nom qu'ils ont donné à leur base de données de graph) est découplée de l'état du jeu simulé. Ainsi, la couche de réplication est comme un cache pour le graph d'entités. Pensez à la couche de réplication comme à un médiateur entre deux personnes. La couche de réplication parle à A et il parle aussi à B. Mais A et B ne se parlent jamais. Ainsi, le serveur et le client communiquent tous deux avec la couche de réplication, qui communique avec le graphe d'entités pour stocker/récupérer les données. Le serveur n'a donc pas à attendre les mises à jour du graph d'entités, tout est dans la couche de réplication, tout est déjà visible pour le serveur. Lorsque nous parlons de données de base, cela signifie les entrées de la base de données qui stockent toutes les données relatives à chaque entité non-joueur. Comme un vaisseau par exemple.

     

    Maillage statique des serveurs

    Vous avez peut-être commencé à comprendre pourquoi le maillage est maintenant possible et non possible auparavant. Auparavant, le maillage n'était pas possible car qui était l'autorité finale dans le maillage du serveur ? Le serveur 1, le serveur 2 ou le serveur 3 ? Ils exécutent tous la simulation, ils ont chacun leur propre état ! Ainsi, sur les serveurs 1 et 2, le gardien du bunker est à l'étage 1, mais sur le serveur 3, il est à l'étage 2. Impossible de fonctionner. Ils ont donc frappé tous les serveurs sur la tête avec un bâton et ont amené un nouveau chef qu'ils ont appelé la couche de réplication. La couche de réplication est l'autorité finale et les serveurs dans un maillage lui rendront tous des comptes. C'est le patron et il utilise le graph d'entités. Le graph d'entité est sa secrétaire, le graph d'entité garde toutes les notes et lui rappelle plus tard ce qui est quoi, afin qu'il puisse dire aux serveurs ce qui est quoi. Donc tous ces 100 000 sites de crash ? Graphiquement, ils ne sont pas rendus, donc le client n'a rien à craindre. Si personne n'est dans les parages, ils sont diffusés en continu, et l'état est capturé par la couche de réplication et stocké dans la base de données graphique de l'entité. Ainsi, le patron dit à sa secrétaire ce qui est quoi et où tout se trouve et la secrétaire prend toutes les notes. La base de données est donc découplée, vous vous souvenez ? Ainsi, le DGS (serveur de jeu dédié ou serveur en abrégé) ne s'inquiète pas du fait que le graph d'entités doive stocker des informations sur cent mille épaves. Le DGS ne détient plus ces informations et ne communique plus avec elles dans le cadre de ses fonctions. Il ne communique qu'avec la couche de réplication. Grâce à ce découplage, le DGS (serveur de jeu dédié) n'est pas encombré par ce genre de choses et dispose de plus de ressources pour faire son travail, ce qui signifie des taux de réussite plus élevés.

    Ainsi, comme la secrétaire gère essentiellement la vie du patron (couche de réplication) et qu'il ne peut pas survivre sans elle, il n'a pas besoin de se rappeler où il a mis cette tasse sur Aberdeen, son graph d'entité de secrétaire s'en souviendra pour lui.

     

    Maillage dynamique des serveurs

    Ce qui a été décrit ci-dessus dans le Maillage Statistique est fondamentalement la base qui améliorera le taux de tic-tac du serveur comme on l'appelle. C'est le cœur de la technologie. Le maillage des serveurs sous sa forme statique consiste simplement à déterminer manuellement un nombre défini de serveurs pour exécuter la simulation. Et il faut garder les coûts à l'esprit. Il ne faut pas que la simulation soit surpuissante, ce qui entraînerait un gaspillage d'argent pour les serveurs, ni qu'elle soit sous-puissante et que l'expérience de l'utilisateur soit mauvaise. Ils vont donc expérimenter le nombre de joueurs simultanés dans un maillage statique efficace et rentable tout en travaillant sur le maillage dynamique. Le maillage dynamique est le logiciel qui déterminera quand de nouveaux serveurs seront lancés pour alléger la simulation en fonction du nombre de joueurs ET de ce qu'ils font. C'est pourquoi PES a été la base du maillage des serveurs. Parce qu'ils ont dû séparer l'état de la simulation pour que les serveurs puissent alimenter différentes parties de la simulation parce qu'ils ne la contrôlent plus, vous vous souvenez ? La couche de réplication la contrôle et indique au serveur quelles entités sont à quel endroit. L'état comme ils l'appellent. Et rappelez-vous, l'état est découplé de la simulation. Le serveur ne gère plus les données des entités non-joueurs.


     

    Trad : @Maarkreidi Starcitizeninfo.fr

     



    Retour utilisateur

    Recommended Comments

    Dur de lire ça de bon matin , mais franchement on comprend mieux les choses .

    Partager ce commentaire


    Lien vers le commentaire
    Partager sur d’autres sites


  • Statistiques des forums

    7,5k
    Total des sujets
    23,7k
    Total des messages
  • Prochain événement

  • Parlez-en à un ami

    je suis complètement dingue du Site des Swiss Starships, Il faut absolument que j'en parle à tout le monde !
  • Je soutiens les Swiss Starships

    Que ce soit pour soutenir

    les Swiss Starships



    Ou pour faire un versement sur le compte de l'Intergalactique Swiss Starships Banque


    Choisissez le montant de votre don et cliquez sur le bouton

    "Je  soutiens "



    18% de l'objectif atteint... MERCI
    Donate Sidebar by DevFuse
×
×
  • Créer...