Je suis Ben Dunkin, programmeur en chef du moteur de l’équipe de Guild Wars 2. J’ai intégré ArenaNet l’année dernière, pour rejoindre la nouvelle équipe du moteur. Notre équipe a également travaillé sur la mise à jour vers DirectX 11. Ce projet se passe bien, mais aujourd’hui, je vais plutôt parler d’un autre projet sur lequel nous travaillons : le remplacement de CoherentUI par Chromium Embedded Framework !
Que remplaçons-nous ?
Nous remplaçons CoherentUI, une bibliothèque qui nous permet de gérer un navigateur Web dans le jeu. Nous utilisons CoherentUI à de nombreux endroits, notamment les livres dans le jeu, le client et le comptoir. Nous allons la remplacer par Chromium Embedded Framework (que nous appellerons « CEF »). CEF est utilisé pour créer les interfaces utilisateur de nombreux autres programmes, comme Steam, le client Battle.net et celui d’Epic Games.
Pourquoi effectuons-nous ce remplacement ?
L’équipe du moteur s’est concentrée notamment sur la modernisation de la base de code. Une grande partie du code du jeu n’a pas changé depuis longtemps. Cela devient problématique pour nous, car nous poussons déjà les vieux systèmes au-delà de leurs limites. Un nombre conséquent de problèmes est dû à nos bibliothèques tierces (des morceaux de code que nous obtenons auprès d’autrui). Parmi ces problèmes figurent DirectX 9 (qui gère le rendu de l’écran), Havok (qui gère la physique), Umbra (qui gère l’élimination des objets cachés) et CoherentUI (qui gère une partie de nos interfaces utilisateur).
Certaines bibliothèques sont difficiles à mettre à jour, et nécessitent une préparation minutieuse ainsi qu’une analyse de rentabilité avant d’être améliorées. Nous avons décidé de passer de DirectX 9 à DirectX 11 (voir notre précédent article de blog ici). Cela a demandé beaucoup d’efforts, mais nous estimons que le résultat en vaut la peine. D’un autre côté, nous avons décidé de ne pas mettre à jour Havok. Cette bibliothèque est intégrée au jeu de manière encore plus intriquée que l’était DirectX 9, et son remplacement risquerait d’introduire des bugs de physique susceptibles d’affecter trop grandement le jeu.
CoherentUI est une bibliothèque beaucoup plus simple à mettre à jour, et nous l’avons choisie pour plusieurs raisons :
- CoherentUI ne prend pas en charge les nouvelles normes de sécurité. Nos partenaires de traitement des paiements tiers nous ont signalé que cela poserait un problème à l’avenir. Il s’agit d’un risque important qui aurait des répercussions sur notre capacité à financer le développement futur de notre jeu.
- CoherentUI n’est plus pris en charge par son vendeur. Nous ne pouvons pas améliorer ses performances ni corriger ses bugs par nous-mêmes. Cela débouche sur des bugs et des problèmes de performances concernant le comptoir que nous ne pouvons pas rectifier.
- CoherentUI est une vieille bibliothèque. Elle a des capacités limitées en termes de développement, de formatage et de normes de langage modernes, et elle n’est pas prise en charge par les outils modernes qui nous aideraient à coder plus rapidement avec elle.
CEF répond à tous ces points et va plus loin encore. Les processeurs de paiements lui font confiance, ses performances sont bien meilleures, et elle prend en charge les outils et normes les plus récents. Elle nous offre également de nombreuses manières d’améliorer davantage les performances, si besoin est. Nous prévoyons de le mettre régulièrement à jour, afin de ne pas prendre de retard sur les améliorations de performance et sur les corrections de bugs.
Vous aurez peut-être remarqué que nous avons amélioré CoherentUI l’année dernière, alors pourquoi procédons-nous à une autre mise à jour ? Nous avons procédé à l’amélioration en question l’année dernière afin de répondre temporairement au premier point listé ci-dessus, pour avoir le temps de remplacer entièrement CoherentUI. Les prestataires de traitement des paiements se sont satisfaits de la nouvelle version de CoherentUI, mais nous savions qu’elle finirait par ne plus respecter leurs normes.
Que verrez-vous une fois ce changement réalisé ?
Vous remarquerez peut-être que le comptoir s’exécutera plus fluidement, mais pas grand-chose d’autre. Notre objectif est de remplacer le système sous-jacent de la manière la plus transparente possible. Nous souhaitons garantir que la mise à jour fonctionne correctement avant de chercher à améliorer les performances ou les fonctionnalités.
Néanmoins, il existe d’importantes différences entre CoherentUI et CEF que vous ne verrez pas, mais qui nous permettront de développer plus rapidement. Par exemple, voici le site Web de Guild Wars 2 tel qu’affiché par les deux bibliothèques.
Affichage par CoherentUI de www.guildwars2.com :
Affichage par CEF de www.guildwars2.com :
Vous pouvez constater que CoherentUI n’affiche pas correctement la barre en haut, le menu déroulant, les éléments d’actualités et la navigation par carrousel. Avec CEF, nous n’aurons plus besoin de contourner ce type de limitations, nous pourrons donc développer l’interface utilisateur plus rapidement.
Voici un profil de performances lors du chargement du comptoir.
Chargement par CoherentUI du comptoir :
Chargement par CEF du comptoir :
CoherentUI nécessite 19,241 millisecondes, tandis que CEF n’en prend que 6,99. À titre de référence, un jeu qui tourne à 60 images par seconde affiche une image entière en 16,66 millisecondes. Comme vous pouvez le constater, CEF ne prend que 36 % du temps que requiert CoherentUI pour la même tâche. Cela signifie que nous pouvons passer moins de temps à optimiser l’interface utilisateur basée sur le Web, car elle est déjà rapide.
Remarque : les performances d’interface utilisateur et celles du réseau sont deux choses distinctes. Parfois, le comptoir semble lent car les requêtes réseau prennent beaucoup de temps, mais l’interface utilisateur n’est pas en cause. Le passage à CEF ne résoudra pas la lenteur des requêtes réseau.
Stratégie de publication
Après notre précédente tentative de publication de cette mise à jour (immédiatement suivie par une marche arrière), j’ai vu plusieurs personnes poser une question pertinente : pourquoi ne pourrions-nous pas mettre cela en place graduellement, ou en permettant aux gens de choisir d’y participer ou non, comme avec DirectX 11 ?
Notre option privilégiée serait la publication graduelle, toutefois des complications nous en empêchent. Nous ne possédons actuellement pas les outils pour publier cette mise à jour lentement, et ces mêmes complications s’appliquent également à l’ajout de nouveaux outils.
Pour mettre en place graduellement la mise à jour, le jeu doit contacter nos serveurs avec un identifiant de compte, pour que nous puissions lui dire si ce compte utilise le nouveau système. Le client s’exécute avant la connexion du joueur, ce qui pose un problème de « cercle vicieux » : nous avons besoin d’un identifiant pour déterminer le système à utiliser, mais nous avons besoin du système pour obtenir un identifiant. Le même problème s’applique aux listes de participants. Les paramètres dépendent du compte, mais nous n’identifions pas le compte tant que le client n’est pas lancé. L’ajout d’un nouveau système de configuration qui n’utilise pas les identifiants de compte impliquerait de modifier également le client, ce qui signifie que nous aurions les mêmes problèmes pour publier le nouveau système de configuration que pour publier le système CEF. Nous avons décidé de minimiser les risques en ne procédant qu’à un seul changement au lieu de deux, même si nous ajouterons peut-être ce type de système de configuration à l’avenir.
Avec DirectX 11, un échec d’initialisation était une erreur qui pouvait être rattrapée. Cela signifie que le jeu apprenait que l’initialisation avait échoué, mais qu’il était en mesure de réagir à l’erreur. Notre réaction consistait alors à modifier le paramètre pour le régler à nouveau sur DirectX 9, pour qu’au prochain lancement, le jeu démarre correctement. Malheureusement pour nous, les problèmes que nous constatons avec CEF font que le client plante immédiatement, ce qui implique que nous ne pouvons pas automatiquement retourner à CoherentUI. En d’autres termes, en cas de problème, la seule option qu’ont les joueurs est de modifier les marqueurs de ligne de commande. Ces marqueurs sont le dernier recours pour résoudre les problèmes des joueurs, nous considérons donc que même une quantité relativement minime de plantages du client équivaut à l’impossibilité de jouer pour les joueurs.
Ne pas pouvoir jouer représente le pire cas de figure pour les joueurs, c’est pourquoi nous avons annulé aussi rapidement la précédente mise à jour. C’est également pour cela que nous n’aurions aucun intérêt à proposer la mise à jour sous forme de participation volontaire. Pour les personnes qui participeraient et rencontreraient des problèmes, notre seule réponse raisonnable serait d’annuler le changement. La réponse serait donc identique à celle obtenue sans participation, à part le fait que nous aurions moins d’informations, étant donné que seul un petit pourcentage de joueurs serait concerné.
Nous devons trouver un équilibre entre minimiser les perturbations pour les joueurs et maximiser les informations obtenues. Les erreurs que nous constatons sont particulièrement obscures. Seule une faible partie des joueurs y est confrontée, et nous ne parvenons pas à les reproduire en interne. Cela signifie que nous avons besoin que beaucoup de joueurs utilisent le nouveau système, rien que pour recevoir quelques rapports d’erreur. Comme il s’agit d’un système critique et d’une mise à jour nécessaire, nous avons choisi de favoriser la maximisation des informations. Nous allons limiter la période pendant laquelle les joueurs sont susceptibles de ne pas pouvoir jouer, en annulant rapidement la mise à jour si nous recevons suffisamment de rapports de plantage.
État actuel
Notre mise à jour de CEF en date du 14 mars a entraîné suffisamment de problèmes pour que nous décidions de l’annuler. Nous avons corrigé les problèmes que nous sommes parvenus à reproduire, et nous avons mis en place des outils qui devraient résoudre le reste.
Le client et le comptoir sont tous les deux des systèmes essentiels, qui sont testés de manière intensive en interne avant toute tentative de publication. Notre incroyable équipe d’assurance qualité a testé cette mise à jour sur une large gamme de configurations de matériel et de logiciels, mais nous ne pouvons pas tester l’ensemble des milliers de systèmes utilisés par nos joueurs. Au cours de semaines entières de test en interne, nous n’exécutons le client que peu de fois, par rapport au nombre de fois que le font nos joueurs en un seul jour. Nous avons publié la mise à jour une deuxième fois le 18 avril, et si nous observons davantage de problèmes graves, nous annulerons rapidement la mise à jour pour les corriger.
J’ai hâte de découvrir toutes les possibilités que cette mise à jour offrira à nos joueurs !
—Ben Dunkin
