PTR 1.13.5 : Blizzard fait le bilan du Stress test de l'événement d'ouverture d'Ahn'Qiraj

Au cours de la nuit, Pazorax est revenu sur le Stress test ayant eu lieu cette semaine sur le PTR 1.13.5 de WoW Classic pour l'événement d'ouverture d'Ahn'Qiraj. Toute l'équipe était présente et remercie les joueurs ayant participé. Voici quelques détails supplémentaires suite à celui-ci.

Ce que les développeurs ont vu

De nombreux joueurs ont demandé lors des tests si les performances allaient être aussi mauvaises sur le live, alors que d'autres plaisantaient en indiquant que tout était prêt à être déployé. Ou peut-être qu'ils ne plaisantaient pas? L'expérience du Stress test de cette semaine était très similaire à l'ouverture d'origine des Portes d'Ahn'Qiraj en 2006. Il y avait beaucoup de lag, quelques crashs du royaume, et lorsque les joueurs ont abandonné et que la population a diminuée, l'événement s'est finalement terminé. Les développeurs prévoient de faire mieux que ça, mais ne seront pas en mesure d'éliminer le lag entièrement.

Pazorax remercie l’ensemble des joueurs qui étaient bloqués à la fin des trajets aériens, car le problème a été trouvé et corrigé. Comme avec beaucoup de problèmes, une fois la source trouvée, il était simple à corriger et celui-ci s'est avéré contribuer à d'autres problèmes également. À ceux l'ayant remarqué, vous avez amélioré la situation pour tout le monde.

Si vous êtes resté jusqu'à 02h00, les conditions de test ont changé au point que le lag rencontré était proche de ce à quoi les développeurs s'attendent sur le live. L'équipe n'a pas d'autres choix que de faire un compromis entre le lag du royaume et la densité de population. Plus il y a de joueurs, plus il y a de lag, et au final, avec trop de joueurs dans la même zone, le lag devient si mauvais que le serveur est dans l'impasse et redémarre.

Un redémarrage car le serveur pense être dans l'impasse est un crash, mais cela représente un défi particulier. Les autres sortes de crashes se produisent lorsqu'un programme essaye de faire quelque chose de vraiment mauvais, les développeurs trouvent cette chose, la corrige et le problème est résolu. Ce cas est plus difficile car il n'y a pas de problème spécifique, juste beaucoup d'éléments qui vont de plus en plus loin. Il y a toujours des améliorations que les développeurs peuvent faire pour résoudre ce point.

Densité de population

Le premier problème est exponentiel. Imaginez un Blizzard qui touche 10 joueurs, qui applique une aura à chacun d'eux, ralentissant leur mouvement. Pour chaque joueur qui obtient l'aura de ralentissement, les développeurs doivent également envoyer un message à tous les joueurs proches pour les notifier que l'aura a été appliquée. Cela fait un total de 100 messages. 10 joueurs affectés envoient 10 messages chacun (un à celui ayant lancé Blizzard et neuf autres aux joueurs affectés par celui-ci).

 S'il y a 20 joueurs présents dans le Blizzard, c'est quatre fois plus de messages. S'il touche 40 joueurs, c'est 1.600 messages. Doublier le nombre de joueurs multiplie le travail par quatre. Passer de 10 joueurs dans une zone à 100 joueurs dans une zone passe de 100 messages à 10.000 messages pour ce même sort. Il y a déjà un puissant hardware en place, c'est donc une question de comprendre combien de joueurs il est possible de soutenir sans crash, ce qui était un objectif pour le Stress test, et les développeurs ont recueilli d'importantes données en raison du nombre de joueurs ayant participé.

Optimisation du code

C'est un point sur lequel les développeurs travaillent depuis 2004, et au cours des derniers mois, l'équipe a optimisé le code avec cet événement spécifique à l'esprit. Voici quelques exemples.

Premièrement, pensez à l'aura de ralentissement. Que ce passe-t-il si le jeu n'envoie pas les messages d'aura immédiatement ? Si vous touchez 100 joueurs avec Blizzard, avez-vous réellement besoin de savoir à la seconde exacte que chacun d'eux ont eu une aura de ralentissement ? Le serveur le sait directement, bien sur, donc l'aura a son effet, et ralentit leurs mouvements, mais si vous ne voyez pas l'aura sur ces derniers pendant une seconde ou deux, est-ce que cela serait acceptable ? Si cela signifie que le serveur ne crash pas, la réponse des développeurs est oui, et ceux-ci ont donc permis aux messages d'aura d'être retardés. Cela possède également un avantage supplémentaire, car si une autre aura se produit lorsque la première attend d'être envoyée, ces messages peuvent être combinés et être moins nombreux globalement. Cela se traduit par moins de paquets et moins de travail pour le serveur.

Une autre optimisation du code qui a été testée concernait l'orientation. C'est une information sur la direction vers laquelle chaque joueur est pointé. Que se passe-t-il si les développeurs ralentissent ou arrêtent les messages de cet élément lorsque la population atteint un certain seuil ? Il s'avère que le coût est faible : les joueurs semblent bouger un peu lorsqu’ils se déplacent. Lorsqu'une zone est surpeuplée, les joueurs bougent déjà un peu lorsqu'ils se déplacent, cela peut donc être une grande victoire côté performance qui n'a pas d'effet visible. En réalité, Pazorax pense que ce problème est moins sévère avec cette optimisation que lorsqu'elle n'était pas présente.

Les développeurs ont également amélioré les performances sur la décision des envois de messages. Lorsque des milliers de joueurs se réunissent dans une zone, décider qui a besoin de connaitre vos auras et dans quelle direction vous vous déplacez demande beaucoup de travail.

Déplacement des joueurs

Une fois les problèmes précédents résolus, les développeurs ont étudié ce point. Lorsque AQ s'est ouvert en 2006, il y avait des GM téléportant manuellement les joueurs en dehors de la zone afin de permettre à l'événement de se poursuivre. Plus tard, l'équipe a conçu un système automatique pour téléporter les joueurs à l'extérieur. Aujourd'hui, les développeurs ont des téléportations automatiques qui fonctionnent très bien, et ces derniers les utilisent pour contrôler la zone afin que celle-ci se limite au nombre de joueurs où l'expérience est convenable. Silithus aura du lag, mais les développeurs préfère téléporter les joueurs à l'extérieur qu'avoir un crash.

Cet événement couvre une grande partie du sud de Kalimdor, et ne pas être en mesure de se rendre à Silithus ne veut en réalité pas dire que vous avez manqué celui-ci. Il y a des Anubisaths  et des Silithides à tuer à Tanaris, aux Milles pointes, à Féralas et aux Tarides pour les 10 heures suivant la frappe du gong.

Un de plus

Le Stress test de cette semaine a donné aux développeurs une bonne idée de ce que ces limites devraient être et le retour après un crash, mais l'équipe aimerait en apprendre davantage, et prévoit un autre test pour le vendredi 26 juin à 00h00. Les développeurs essayeront de le terminer plus rapidement cette fois-ci, car celui-ci devrait présenter moins de problèmes.