DEVBLOG – Technique

En cette période où la capture des altérés et des kromas est de rigueur, nous vous proposons un format devblog un peu différent. En effet, nous allons parler de sujets techniques finis ou en cours de développement chez DOFUS. Ce devblog sera également l'occasion de revenir sur quelques incidents survenus lors de la mise à jour de mars 2023. L'objectif est de vous partager nos avancements et de vous faire découvrir plus en détail les coulisses des gros chantiers techniques (et les difficultés qu'ils apportent). Ce sera également l'occasion de vous présenter les modifications et avantages que ces sujets vous apportent ou vous apporteront à l'avenir. C'est parti !

 

Un serveur pour les connecter tous

Le premier sujet que nous voulions vous présenter est le nouveau serveur de connexion. De quoi s'agit-il exactement ? Et à quoi sert ce serveur ? Pour faire simple : lorsque vous lancez le jeu à partir du launcher, vous n'arrivez pas directement sur les serveurs de jeu, mais sur le serveur de connexion (oui, le nom est plutôt explicite). Son rôle est multiple : 

• Présenter la liste de tous les serveurs et connaître leur état (allumé, en cours de démarrage, éteint...). Contrairement aux serveurs de jeu, le serveur de connexion doit avoir connaissance de tous les serveurs qui existent (par exemple, le serveur Tylezia ne sait pas du tout que le serveur Hell Mina existe) ;
• Savoir sur quel(s) serveur(s) le joueur a des personnages (pour afficher le nombre de personnages dans la liste des serveurs) ;
• Récupérer les informations de compte du joueur (s'il est abonné ou s'il est banni par exemple) ;
• Faire des vérifications de restrictions de serveur (le monocompte ou le serveur tournoi par exemple) ;
• Et transmettre toutes ces informations au serveur de jeu pour connecter le personnage sur son serveur (y compris pour les reconnexions lors d'une déconnexion en combat).

Historiquement, nous avions trois serveurs de connexion (sobrement appelés co-2, co-3 et co-4).
Lorsque le joueur arrivait en jeu, il était redirigé vers un de ces trois serveurs aléatoirement (sans se préoccuper de savoir s'il était plein ou non). Nous avions également un serveur co-1 qui avait un rôle un peu différent. Il permettait principalement de gérer les « services » au sens large (les bannissements, les modifications de personnage en attente : restaurations, changements de classe, de couleurs, de nom, la liste d'amis/ennemis, les achats et cadeaux en attente, les transactions de la BAK effectuées sur le site...).

Pourquoi vouloir le refaire ?

Plusieurs raisons nous ont poussés à vouloir refaire de 0 le serveur de connexion. Le vrai élément déclencheur a été Temporis 7.

Avec l'ancien serveur, pour changer le statut d'un serveur (de « Fermé » à « Ouvert »), nous étions obligés d'éteindre et rallumer le serveur de connexion pour qu'il prenne en compte ce changement. Ainsi, tous les joueurs qui étaient en train d'attendre sur la liste des serveurs étaient déconnectés lors de l'extinction puis se reconnectaient tous massivement. Lors d'une maintenance hebdomadaire, ce redémarrage se faisait à une période de faible affluence, ce qui ne posait pas de problèmes.

Mais pour l'ouverture d'un Temporis, nous essayons de faire une ouverture dans l'après-midi pour faire en sorte que le maximum de joueurs soient disponibles.
On communique l'heure en amont à nos joueurs et beaucoup d'entre eux sont dans les starting-blocks quelques minutes avant l'ouverture effective. Il en résulte que, au moment de l'ouverture (et donc du redémarrage des serveurs de connexion), ceux-ci doivent gérer énormément de joueurs, ce qu'ils avaient du mal à faire (avec uniquement trois serveurs et une mauvaise répartition des joueurs sur les trois).
L'affluence massive engendrait des latences sur les serveurs de connexion, diminuant d'autant leur capacité à traiter les joueurs en attente, créant un effet boule de neige de latences toujours plus grandes. La file d'attente ne faisait alors qu'augmenter créant encore plus de latence et donc plus de file d'attente...

Pour Temporis 7, nous avions atteint un niveau historique de files d'attente pendant la première soirée, pour lequel nous n'avions aucune solution. Tout était rentré dans l'ordre le lendemain matin, avec un redémarrage en période de creux.

De plus, le serveur de connexion était « d'origine ». Le code de base datait des débuts de DOFUS, et les nombreuses modifications qui ont été faites au fur et à mesure rendaient le système de plus en plus complexe à comprendre et à maintenir. De nombreuses améliorations techniques, qui ont vu le jour depuis 2005 sur les serveurs de jeu, n'avaient pas été répercutées, et le serveur de connexion n'en bénéficiait donc pas.

Enfin, nous avions d'autres problèmes moins visibles pour les joueurs concernant les droits admin des comptes de l'équipe DOFUS, ainsi qu'une surcharge d'appels aux différentes API qui nous permettent de récupérer les données des comptes (abonnement, amis...), saturant à leur tour ces systèmes. Ce système était vieillissant et devait être refait.

En pratique...

Cette refonte du serveur de connexion a été un gros chantier, monopolisant deux développeurs à plein temps durant quatre mois. En effet, depuis sa création, de nombreux ajouts ont été faits au fur et à mesure pour corriger ou ajouter des fonctionnalités. Il a fallu comprendre comment tout cela fonctionnait. Il a également fallu jongler avec l'architecture informatique qui a été choisie à l'époque et qui n'est pas totalement adaptée aujourd'hui. Bref, 90 % du serveur de connexion ont dû être modifiés, seule la partie communication avec le serveur de jeu et le client est encore d'origine (mais plus pour très longtemps...).

Comme parfois sur ce genre de gros sujets techniques, la quantité de modifications et le nombre de cas particuliers font que certains problèmes ne sont découverts que lors de leur mise en jeu. Cela a été le cas lors de la mise à jour du 28 mars. En voici deux exemples : 

• Les restrictions monocomptes : ces restrictions ont été probablement le problème le plus impactant et compliqué à corriger, notamment, car il est difficile de reproduire, en interne, les conditions exactes que les joueurs ont rencontrées. Au cours de la mise en production du nouveau serveur de connexion, nous avons eu deux problèmes :
  • Lorsque le joueur perdait sa connexion internet en jeu, il ou elle était mal déconnecté(e) du serveur de jeu. Ainsi, le serveur de connexion pensait qu'il était toujours en jeu. Lors de sa reconnexion, le joueur était en conflit avec lui-même et, à cause des restrictions monocomptes, était bloqué.
  • Pour vérifier que plusieurs comptes ne sont pas sur le même ordinateur (ce qui est interdit en monocompte), nous identifions avec précision l'information de l'ordinateur. Or, il arrivait, dans de rares cas, que nous n'ayons pas d'identifiant pour un ordinateur. Nous avions donc un identifiant générique. Cependant, cet identifiant générique était commun à tous les joueurs. Ainsi, dès qu'une personne se connectait avec cet identifiant générique, plus aucun autre joueur avec un problème d'identifiant d'ordinateur ne pouvait se connecter.
• Si un joueur perdait sa connexion internet en combat, le serveur de connexion ne savait plus que le joueur était en combat. Ainsi, quand le joueur se reconnectait, le serveur de connexion ne le reconnectait pas en combat. Le personnage était donc expulsé du combat et mourrait immédiatement.

Les opportunités

• Les ouvertures de serveurs sont désormais grandement améliorées et fluidifiées. Que ce soit pour les mises à jour, les maintenances ou les lancements de Temporis, le système peut désormais s'autoréguler et, automatiquement, adapter sa capacité en fonction de l'affluence.  Nous n'avons également plus à déconnecter tous les joueurs du serveur de connexion avant l'ouverture. Nous sommes plus flexibles sur l'ajout ou le retrait de serveurs dans la liste des serveurs.
• Le debug et l'ajout de fonctionnalités sur le serveur de connexion sont désormais plus faciles. Pour prendre un exemple, nous avions un problème de reconnexion en jeu lorsqu'on était déconnecté du Kolizéum. Nous n'arrivions pas à corriger le problème avec l'ancien serveur de connexion, mais ce problème a pu être corrigé avec le nouveau assez facilement.
• Nous pouvons désormais faire des maintenances sur le serveur de connexion beaucoup plus facilement (si on a besoin de corriger quelque chose en urgence par exemple). Ceci nous a notamment permis de corriger plusieurs problèmes les quelques jours après la mise à jour sans avoir eu besoin de faire une maintenance.

Sauvegardes et format des données

Depuis maintenant deux ans, nous avons commencé un deuxième sujet technique important : les sauvegardes en temps réel. Comme d'habitude, un petit rappel sur le contexte, d’il y a deux ans. 

Comment fonctionnaient les sauvegardes en 2021 ?

Chaque action réalisée par un joueur devait être sauvegardée (logique, sinon il aurait perdu des éléments de sa progression). Ces informations étaient enregistrées dans des bases de données, propres à chaque serveur de jeu. En parallèle de cela, certaines informations étaient également enregistrées dans des fichiers textes (et non en bases de données). 

Ces différentes sauvegardes étaient (et sont encore pour certaines) faites à plusieurs moments : 

• À la déconnexion du joueur, on enregistrait toutes ses données (par exemple : sa position sur la carte, son inventaire ou encore son avancée dans les quêtes).
• À l'extinction d'un serveur, certains éléments étaient sauvegardés comme les maisons ou les enclos publics par exemple.
• D’autres éléments étaient sauvegardés dans des contextes particuliers. Par exemple, on sauvegardait l’avancée dans les songes infinis d'un joueur uniquement lorsqu'il en sortait. 
• Et enfin, dans d’autres situations, ces sauvegardes étaient faites en temps réel, dès que l’action se produisait. 

Pourquoi cette disparité entre les systèmes ? Il faut garder en tête que DOFUS fête ses 19 ans cette année, et que depuis ce temps, les possibilités et les contraintes liées aux serveurs et aux réseaux ont bien changé. En fonction de la date d'implémentation des features, certains choix d'optimisation qui ont été faits peuvent désormais être obsolètes.

Vous connaissez aussi certainement les sauvegardes qui sont faites à intervalles réguliers (0 h, 6 h, 11 h et 16 h). Ces backups sont l’occasion de créer une copie de l’état des joueurs à un instant T pour pouvoir les remettre comme ils étaient lors d’un éventuel rollback. Ces sauvegardes sont en plus de la copie de la base de données qui aura été faite au même moment, pour prendre en compte toutes les informations qui ne seraient pas déjà présentes en bases de données. 

Le système de sauvegardes de 2021 avait plusieurs inconvénients :  

• Si le serveur s'éteignait mal ou que des joueurs étaient mal déconnectés, certaines données étaient perdues, ce qui entraînait obligatoirement un rollback. Pourquoi ? On ne pouvait pas savoir qui avait bien été déconnecté et qui ne l'avait pas été. Prenons un exemple : si un joueur A avait donné un objet au joueur B et que le serveur s'était mal éteint alors que les joueurs étaient connectés (avec le joueur B qui était bien déconnecté, mais pas le joueur A). Dans notre sauvegarde, nous aurions donc eu le joueur A qui a encore l'objet (car la disparition de son inventaire n’aurait pas été sauvegardée), mais le joueur B qui l'aurait lui aussi. On aurait donc eu une duplication de l'objet, qui plus est dans deux inventaires différents (et dans le cas inverse où c'était A qui était correctement déconnecté et pas B, alors l'objet aurait tout simplement disparu).
• Le système imposait de faire des backups à intervalle régulier et durant les maintenances (ce qui les rallongeait). Le but est de se passer de ces backups et de faire des maintenances plus rapides. 
• Lorsque nous avions besoin de faire un rollback, nous étions contraints de reprendre les données d'un backup (donc potentiellement de revenir plusieurs heures en amont) au lieu de revenir aux données d’un instant précis. Par exemple, si on identifiait un problème à 15 h, nous devions revenir aux données de 11 h au lieu de revenir à celles de 14 h 55. 

Et le format des données dans tout ça ?

Au cours du temps, les données ont été enregistrées sous différents formats (en fonction du besoin, des systèmes de sauvegarde existants, des capacités de stockage disponibles à cet instant). Certains d'entre eux sont encore faciles à utiliser aujourd'hui. Cependant, un format de donnée compressé et optimisé nécessitant peu d'espace de stockage a historiquement été choisi, notamment en ce qui concerne les données conséquentes. Ce dernier nous cause aujourd’hui beaucoup de problèmes, d'où la nécessité de le modifier en même temps que la façon dont les données sont sauvegardées. 

En effet, ce format a plusieurs défauts, notamment sa lisibilité et sa facilité à trouver où ajouter une information. Le format compressé est une représentation simplifiée, qui correspond à une succession de caractères séparés par des caractères spéciaux (_, |, etc.). Pour prendre un exemple, la chaîne de données d'un inventaire peut être vraiment très longue (chaque objet dans l’inventaire est séparé par un caractère spécial, et chaque objet est lui aussi décomposé en plusieurs sous-informations, séparées à leur tour par un autre caractère spécial, pour connaître sa quantité, sa position dans l’inventaire, ses effets, etc.). Ce format nous bloque dans l'ajout de nombreuses fonctionnalités que nous aimerions implémenter en jeu.  

Les modifications effectuées

Il a été fait le choix d'adopter un format différent pour certaines de ces données. Bien que moins optimisé au niveau de l'espace de stockage, il est plus adapté à notre besoin, plus lisible et nous permet de manipuler beaucoup plus facilement ces données. Il nous permet notamment de facilement cibler une valeur et de sauvegarder uniquement celle-ci au lieu de devoir sauvegarder toutes les données à la moindre modification. Passer à ce nouveau format de données a également été l'occasion de faire le ménage dans les données sauvegardées et de supprimer celles qui ne sont plus utiles. 

Pour les sauvegardes, le changement a pu être fait en plusieurs étapes et est toujours en cours aujourd'hui.
Durant l'année 2022, nous avons, dans un premier temps, supprimé toutes les informations enregistrées dans les fichiers textes pour les sauvegarder avec le reste, dans les bases de données dédiées.
De plus, depuis maintenant un an, nous travaillons sur nos mises à jour en faisant en sorte d'enregistrer en temps réel les données et d'avoir directement le format le plus flexible possible. C'est notamment le cas des guildes, des altérations ou encore des alliances plus récemment. Pour toutes les autres données (puits des songes infinis, maisons, hôtels de vente, enclos, étables, inventaires, caractéristiques... pour ne citer qu'eux), nous repassons progressivement dessus pour les modifier. Ainsi, les maisons sont sauvegardées en temps réel depuis le 20 septembre 2022, les hôtels de vente depuis le 14 février 2023, les puits des songes infinis depuis le 1^er mars 2023, etc.

Tout n'est cependant pas encore converti dans le format de données qu’on souhaite avoir à terme, ni sauvegardé en temps réel. Il nous reste certains des sujets les plus sensibles (inventaires, banques, caractéristiques, étables). Certains sont déjà finis et subissent actuellement une vague de tests intensifs pour être sûrs de ne rien louper. Nous attendons également le moment le « moins dérangeant » pour les mettre en jeu (nous privilégions les périodes plus creuses pour minimiser l'impact de possibles problèmes). 

Parce que, en effet, il peut y avoir des problèmes. Ce devblog est l'occasion de revenir sur trois problèmes survenus en jeu à la suite de ces modifications : 

• Lors de la mise à jour du 28 mars 2023, nous avons changé le format de données des enclos et des certificats de montures. Le format des étables n'a, quant à lui, pas changé. Quelques dizaines de minutes après la réouverture des serveurs, nous avons identifié un problème avec la cohabitation entre ces deux formats. En effet, lors du passage d'une monture de l'étable à l'enclos (et inversement), l'information de fécondation des montures était mal transmise d'un format à l'autre. L'ancien format de données (utilisé par les étables) gérait mal cette perte d'information, ce qui provoquait une erreur lors de sa sauvegarde. L'étable était alors sauvegardée comme n'ayant aucune monture dedans. 
• Lors de la modification de la sauvegarde des enclos durant la mise à jour du 28 mars, nous avons observé que la sauvegarde de la fatigue des montures était incomplète. Lors de la maintenance du 16 mai, nous avons voulu corriger ce problème. Le correctif est passé. Cependant, quelques heures après la fin de la maintenance, nous nous sommes rendu compte que la demande de sauvegarde était envoyée à chaque modification de la position de chaque monture dans un enclos, ce qui engendrait beaucoup trop de demandes par rapport à ce que le serveur pouvait traiter. Nous avons donc dû faire une maintenance exceptionnelle le lendemain (17 mai) pour retirer cette sauvegarde le temps de trouver une autre solution. Depuis, une optimisation a été faite pour envoyer moins de demandes de sauvegardes et le sujet a pu arriver en jeu lors de la maintenance du 8 août sans encombre.  
• Depuis plusieurs mois, les succès sont sauvegardés en temps réel au format souhaité. Cependant, la conversion de l'ancien format de données vers le nouveau ne se fait qu’à la connexion du joueur. Lors de la maintenance du 30 mai, nous avons voulu appliquer le changement de format de données à tous les personnages qui ne s'étaient encore jamais connectés. Malheureusement, au cours de la maintenance, nous nous sommes rendu compte que le stockage de tous les succès de tous les joueurs était beaucoup trop volumineux, ce qui allait considérablement augmenter le temps des différents backups (lors des maintenances ou à intervalles réguliers). Nous avons donc dû stopper la migration et faire un rollback avec le backup de début de maintenance (d'où l'utilité d'en faire un avant de commencer une maintenance). Des optimisations sont en cours sur les données sauvegardées et le format pour qu'elles soient moins volumineuses.

En parallèle, nous sommes en train de faire des tests pour l'utilisation de technologies de base de données différentes, plus performantes et ainsi réduire le temps nécessaire à la création de ces backups. Le serveur Ombre a été notre cobaye pour ces tests lors de la maintenance hebdomadaire du 12 septembre, ce qui explique qu'il a été inaccessible plus longtemps.

Les opportunités

Bien que ces modifications aient causé certains problèmes lors de leur mise en place, tout comme le nouveau serveur de connexion, elles ont surtout vocation à apporter un lot d'améliorations et de futures fonctionnalités :  

• Comme dit précédemment, les rollbacks devraient être moins fréquents et, lorsque nécessaires, reviendront à une sauvegarde moins éloignée dans le temps. 
• Le temps des maintenances sera, dans une certaine mesure, réduit. C'est une première étape obligatoire pour pouvoir réduire drastiquement le temps de ces dernières. 
• Avec le changement de format des données, de nombreuses opportunités s'ouvrent à nous : 
  • Pouvoir créer des catégories d'objets personnalisées 
  • Pouvoir verrouiller certains objets dans son inventaire 
  • Faciliter les injections de fin de serveur Temporis 
  • Pouvoir plus facilement retrouver des objets dans les inventaires des joueurs en cas de problèmes
•  Lorsque tout sera sauvegardé en temps réel, nous pourrons enfin débloquer la possibilité de réaliser des transferts de serveur à tout moment, sans être dépendants des maintenances hebdomadaires (cette fonctionnalité est le « boss de fin » du chantier des sauvegardes). 
• … et ce n'est qu'une liste non exhaustive des possibilités qu'offrent ces modifications.

Conclusion

Sacré pavé de texte... Merci d'avoir pris le temps de lire ce devblog. Nous avons bien conscience que les modifications techniques sont des sujets annexes pour beaucoup d'entre vous. Généralement, ce qui est visible pour le joueur, c'est que certaines maintenances apportent parfois des bugs. J'espère avoir réussi à vous partager les principaux challenges que ces sujets apportent et vous avoir fait entrevoir les raisons qui nous ont poussés à les faire. Bien que risqués, ces changements sont impératifs pour un futur pérenne du jeu et pour vous apporter de nouvelles fonctionnalités jusqu'alors impossibles.

Pour les personnes intéressées par les sujets techniques, j'espère avoir réussi à vous partager les informations essentielles et vous avoir intéressés tout au long de ce devblog. Et pour les autres, d'autres devblogs sur des sujets plus gameplay arrivent très bientôt...