Après avoir soigneusement étudié les dysfonctionnements du gadget d'Hibana, nous les avons normalement presque tous résolus. Avec la mise à jour 2.1.1, disponible le 11 juillet sur toutes les plateformes, vous constaterez que le X-KAIROS d'Hibana est désormais bien plus fiable.
Le cas : Hibana, un concept unique
Avant l'annonce de l'Opération Health, vous nous aviez déjà signalé des soucis rencontrés avec le X-KAIROS. En étudiant leur origine, notre équipe a découvert des problèmes fondamentaux au niveau de l'architecture du gadget, c'est pourquoi nous avons décidé de revoir toute la gestion des projectiles. Nous en avons parlé avec Alex Busby, programmeur des animations, qui a analysé notre approche initiale des mécaniques d'Hibana et cherché des solutions pour résoudre ces problèmes une bonne fois pour toutes.
Pour commencer, nous devons vous présenter les particularités d'Hibana par rapport aux autres agents. Nous serons ensuite plus à même de vous expliquer les problèmes que vous avez peut-être rencontrés, et qui découlent de sa conception particulière. Hibana utilise son gadget pour projeter jusqu'à six plombs qu'elle peut par la suite faire exploser sur commande. Pour la créer, l'équipe a divisé l'agent en plusieurs parties (appelées "objets .NET") : son corps, son gadget (le X-KAIROS) et les six plombs. Aucun autre agent n'est composé d'autant d'objets .NET actifs simultanément.
"Même si nous avions déjà Ash qui fonctionne de manière similaire, c'est la première fois que l'on peut tirer plusieurs fois des munitions et qu'il existe différentes phases au cours desquelles vous pouvez projeter plus de plombs, en déclencher certains, ou encore recharger." - Alex Busby, programmeur des animations
Les objets .NET, qu'est-ce que c'est ? Pour que les différentes actions d'un match puissent se dérouler normalement, on doit les dissocier pour pouvoir parfois les traiter dans le désordre si nécessaire. Pour que tout cela garde un sens, on soumet ces actions à des autorités, nommées autorités hôtes ou locales, qui s'assurent que tout se déroule de la manière attendue par les joueurs. Pour simplifier, une succession d'événements se déroule à la fois sur le serveur et sur la machine de chaque joueur. S'il y a un désaccord, l'autorité hôte privilégie les informations du serveur, tandis que l'autorité locale donne la priorité aux informations envoyées par la console ou le PC. En général, ces calculs et ces comparaisons ont lieu si vite que le joueur ne peut pas percevoir ces conflits.
Le problème : conflits entre autorités hôtes et locales
Contrairement aux autres agents, avec Hibana, nous devions surveiller un grand nombre d'événements, comme sa propre position (au cas où un autre joueur la repère et lui tire dessus), son X-KAIROS (qui prévient le serveur de son orientation, lorsqu'il est déchargé et quand il peut être rechargé), ainsi que les six plombs (qui signalent leur position et leur état d'activation). Pour pouvoir suivre tous ces événements avec précision, nous avons attribué à chaque élément un objet .NET chargé de communiquer les informations au serveur.
Toutefois, après la sortie d'Hibana, nous avons constaté que nos serveurs avaient des difficultés à gérer toutes les informations envoyées pas les différents objets .NET. Par exemple, il arrivait qu'au moment où le X-KAIROS d'Hibana projetait ses six plombs, le flot d'information soit parfois interrompu à cause une latence ou d'une connexion de qualité insuffisante. Ces messages confus occasionnaient de nombreux dysfonctionnements du gadget, et nous avons constaté que ces problèmes se présentaient car nous avions affecté des autorités différentes aux différentes étapes.
La solution : rationalisation des objets .NET
Après avoir travaillé plusieurs mois d'arrache-pied, nous avons rationalisé la gestion des objets .NET d'Hibana. Nous avons commencé par réduire le nombre d'objets .NET qui nécessitent une surveillance. Grâce à cela, le nombre de conflits potentiels entre les deux autorités a été réduit et les joueurs ne subiront plus les complications liées à la désynchronisation des autorités.
"Nous voulions garder le plus de réactivité possible ; c'était le fil conducteur de cette correction. Nous avons repéré les problèmes ou les risques de désynchronisation, et essayé de placer un maximum d'éléments sous l'autorité hôte." - Alex Busby, programmeur des animations
De plus, nous avons aussi étudié de près toutes les situations où nous avons constaté des problèmes liés à l'utilisation du gadget, comme le placement des plombs et les erreurs visuelles, et nous les avons corrigées. Vous en saurez plus sur toutes les corrections de la mise à jour 2.1.1 avec les notes de version qui seront publiées lundi 10 juillet.
Non seulement ces changements amélioreront la jouabilité d'Hibana, mais cela nous offrira aussi la possibilité de créer plus tard d'autres gadgets avec un fonctionnement aussi complexe.
Nous espérons que cette explication vous aidera à comprendre les problèmes rencontrés avec Hibana et la raison pour laquelle nous devions leur consacrer du temps pour les rectifier au cours de l'Opération Health.
Merci à toutes et à tous pour votre soutien sans faille !
