Analyse serveur – La puissance du beau

Capsuliers,

Il est temps de poursuivre la conversation autour de Quasar, l'écosystème sous-jacent au développement moderne dans EVE Online. Depuis son introduction au Fanfest 2022, il est devenu la fondation de plusieurs avancées majeures, dont :

Ce voyage, dans le cadre d'EVE Evolved, a abordé la théorie des ensembles, la théorie des graphes et, euh… la théorie des couleurs. Aujourd'hui, cependant, l'accent est mis sur la technologie alimentant les SKINS de vaisseaux créés par les capsuliers, car elle est bien plus qu'un simple éditeur et une magie de shader ! En fait, il s'agit d'un élément essentiel des efforts pour permettre les capacités futures en termes de performances du serveur. Préparez-vous, cependant, car quelques cours intensifs de technique seront nécessaires pour comprendre les tenants et aboutissants de ce que l'équipe a réalisé.

Netcode et Tick Rate

L'un des défis les plus courants dans les jeux multijoueurs est leur architecture réseau, familièrement appelée « netcode ». Que ce soit pour garantir une expérience cohérente pour tous les joueurs ou pour prévenir la triche, la manière dont les informations sont transmises aux clients du jeu joue un rôle crucial dans la performance et le plaisir global. Un facteur clé ici est le taux de rafraîchissement - la fréquence à laquelle le serveur de jeu met à jour et envoie des informations aux clients connectés.

Différents moteurs de jeu adoptent cette approche de diverses manières. Unreal Engine, par exemple, met l'accent sur le filtrage de pertinence, envoyant uniquement les mises à jour les plus importantes à chaque client, tandis que Source Engine se concentre sur la prédiction des entrées, réduisant ainsi le nombre de corrections nécessaires pour assurer une expérience de jeu fluide.

Quelle que soit l'approche, le taux de rafraîchissement reste un facteur fondamental dans la performance du réseau. La plupart des jeux fonctionnent entre 20 Hz et 120 Hz, en fonction du nombre de joueurs en ligne, ce qui signifie que les mises à jour sont envoyées entre 20 et 120 fois par seconde par client. Par exemple, à 60 Hz, le serveur doit traiter et envoyer des mises à jour toutes les 16,6 millisecondes pour assurer que 60 mises à jour puissent se produire en une seconde, et laisser de la place pour que d'autres joueurs reçoivent la même information dans le même laps de temps. En supposant une connexion Internet sans latence magique permettant aux clients de recevoir directement l'état du jeu dès la connexion (faisons comme si cela existait), un serveur à 60 Hz traiterait les mises à jour de l'état du jeu de cette manière :

Deux tics d'un serveur à 60 Hz

La prédiction des entrées et l'interpolation des mouvements peuvent créer l'illusion d'une interaction en temps quasi réel, même sans un Internet à latence nulle. Cependant, à mesure que les taux de rafraîchissement diminuent, les délais deviennent plus perceptibles. Cela semble préjudiciable, n'est-ce pas ? Alors, pourquoi souhaiteriez-vous un taux de rafraîchissement plus faible ?

Eh bien, EVE Online existe depuis l'époque des modems 56k. Pour maintenir les prérequis de bande passante suffisamment bas pour les grandes batailles spatiales, la fréquence de rafraîchissement du serveur a été réglée à une seconde.

Plus précisément, la fréquence de la simulation physique est de 1 Hz, ce qui réduit considérablement la nécessité d'envoyer des mises à jour aux clients de bureau.

D'autres interactions avec les éléments qui n'affectent pas la physique sont traitées aussi rapidement que le permettent les hamsters Python. Cela signifie que si une entrée est envoyée juste avant un tick, elle semble très réactive. Si elle est envoyée juste après, il peut sembler qu'il faille une seconde ou même plus pour observer un effet (en tenant compte de la latence du monde réel – GG, Australie). Techniquement, vous pourriez donc vous synchroniser parfaitement avec le serveur en appuyant sur une touche exactement une fois par seconde, mais bien sûr, pour le bien-être mental, il peut être très important de cliquer sur « sauter » trente fois par seconde.

En observant de manière holistique Tranquility en moyenne sur l'année écoulée, il est évident que le nombre d'opérations par seconde est proportionnel au nombre de capsuliers actifs dans la galaxie. En moyenne, chaque session traite environ 0,7 opérations par seconde, démontrant ainsi l'efficacité avec laquelle EVE Online transmet uniquement les données nécessaires.

Les chiffres fluctuent, bien sûr, et ce sont tous des moyennes. Lorsque les combats de flotte atteignent les limites de traitement, la dilatation du temps (TiDi) s'active. Si vous êtes curieux de connaître les détails techniques, vous pouvez consulter les archives sur TiDi pour en apprendre davantage.

Et les SKINS dans tout ça ?

Dans EVE Online, presque tous les mécanismes cosmétiques sont transmis via des trames de simulation, la version d'EVE d'un tick. Avant SKINR, les changements de SKIN de vaisseau étaient livrés avec la prochaine trame de simulation envoyée à tous les clients pertinents. Autrement dit, les mises à jour de SKIN ne pouvaient se produire qu'une fois par seconde. Même sans aucune limite de fréquence sur l'IU ou les requêtes réseau, peu importe la rapidité avec laquelle vous changiez de SKINS, personne ne pourrait observer plus d'une mise à jour par seconde, car c'est la limite imposée à la transmission des trames de simulation.

Il y a également un autre problème : fanout. (Dernier cours accéléré, je vous le promets.)

Lorsque vous modifiez le SKIN de votre vaisseau, la mise à jour doit être envoyée à de multiples destinataires – ce que l'on nomme le « fanout ». Mais quels sont ceux qui doivent recevoir l'information ? Que se passe-t-il si vous êtes près d'une centaine d'autres vaisseaux ? Que signifie réellement « près », et qui sont ces cent autres ?

Les trames de simulation gèrent les deux problèmes en traitant uniquement les mises à jour pour les vaisseaux situés dans la même bulle (couramment appelée grille, à ne pas confondre avec les bulles de perturbation de warp). Cette méthode a cependant un coût, car plus de données par trame de simulation signifient plus de sérialisation et de fanout pour le serveur simulant ce système solaire. Auparavant, Quasar ne suivait que le système solaire dans lequel se trouvait un vaisseau, mais pour que SKINR fonctionne en temps réel, il devait également suivre le mouvement des vaisseaux entre bulles.

Ce n'était pas un petit exploit. Il a fallu apporter des modifications profondes au moteur de simulation principal d'EVE Online pour permettre à Quasar d'accéder à son état d'une manière inédite. Le résultat a été stupéfiant ! Une multiplication par 27 des données traitées comparativement aux simples transitions entre systèmes solaires.

Voici une comparaison des événements par seconde entre le voyage dans le système solaire et le voyage en bulles : gardez à l'esprit que la perturbation de warp traverse plusieurs bulles, et non pas seulement « A à B ».

Et cela concerne uniquement le trafic interne, avant même de prendre en compte le problème de fanout !

Résoudre le défi de Fanout

Maintenant, revenons au scénario « un vaisseau change son SKIN près de 100 autres vaisseaux ». Avec Quasar qui suit tous les vaisseaux dans toutes les bulles, il comprend maintenant ce que signifie « près » et quels clients doivent recevoir des mises à jour. Au lieu d'attendre la prochaine trame de simulation, Quasar envoie immédiatement les changements de SKIN à tous dans une bulle donnée.

Ceci est rendu possible grâce à la messagerie du puissant NATS, qui gère efficacement environ 10 000 messages envoyés chaque seconde aux clients d'EVE. Des services comme ceux qui gèrent l'état des articles cosmétiques peuvent maintenant sérialiser et envoyer une mise à jour de SKIN unique, qui est ensuite diffusée à tous les vaisseaux à proximité, au lieu d'être retardée par le tick de simulation de 1 Hz.

Ceci est démontré dans cet extrait rapide d'un test de jeu SKINR :

La question devient : Pourquoi est-il important que Quasar puisse suivre les emplacements de vaisseaux et envoyer des mises à jour d'articles cosmétiques indépendamment ? Parce que cette technique permet à EVE Online de décharger une fonction purement cosmétique du moteur de simulation principal.

En outre, cela a des implications plus larges lorsqu'on considère tous les autres effets cosmétiques qui doivent être sérialisés et distribués aux clients. Une fois la conversation dépassant les articles cosmétiques, la question naturelle devient : que peut-on encore déléguer à Quasar ?

Repousser les limites

Pour mettre le système à l'épreuve, une partie du test de masse de SKINR a consisté à supprimer la limite de l'IU lors du changement de SKIN pour voir ce qui se produirait. Le résultat ? Un effet visuel plutôt intéressant :

La partie amusante a commencé lorsque le véritable test de charge a débuté, avec 500 joueurs modifiant simultanément des SKINS dans la même bulle sur un serveur de test peu performant. Cela a entraîné un pic d'environ 45 000 messages par seconde !

Un grand merci à tous ceux qui participent à ces types de test de masse. Il n'est peut-être pas toujours évident que votre contribution est précieuse, mais cela illustre clairement l'impact de votre participation.

Pour revenir à l'exemple chaotique mentionné précédemment, que visait-il exactement ?

En examinant les statistiques antérieures, Tranquility gère typiquement environ 30 000 messages par seconde sur l'ensemble du serveur, ce qui lui confère une moyenne agréable d'environ une opération par seconde, soit 1 Hz. En revanche, le test de SKINR a atteint 45 000 messages par seconde avec seulement 500 joueurs, signifiant que Quasar délivrait effectivement des mises à jour à 90 Hz dans ce scénario.

Si Quasar peut gérer un trafic de 90 Hz pour 500 joueurs sur un serveur de test à petite échelle exploitant seulement trois nœuds, que pourrait-il accomplir en étant étendu à la pleine puissance de 230 nœuds Tranquility avec 30 000 joueurs actifs ?

Que se passe-t-il si les trames de la simulation suivent elles-mêmes le même paradigme ?

Que se passera-t-il si les trames de simulation n'ont plus à attendre une seconde entière pour être envoyées ?

Quelles implications cela a-t-il pour la dilatation du temps ? La Méta change-t-elle lorsque les batailles se déroulent en temps réel à grande échelle ?

Si la fidélité du réseau peut être augmentée 90 fois, quelles nouvelles expériences les concepteurs peuvent-ils offrir aux pilotes de New Eden ?

Voici les questions qui façonneront l'évolution d'EVE Online, et certaines pourront être abordées sur CCP TV à 15 h 00 le 20 février, alors assurez-vous de vous connecter.

o7