« C’est tout simplement impossible : Les développeurs expliquent pourquoi les grands jeux en ligne semblent toujours se casser la figure au lancement.

1. Serial Gamers -
2. Apex Legends – Battle Royale sur PS4, Xbox One et PC : Test & Avis -
3. Apex Legends Battle Royale : Actualités & nouveautés -
4. « C’est tout simplement impossible : Les développeurs expliquent pourquoi les grands jeux en ligne semblent toujours se casser la figure au lancement.

Entre le lancement fragmenté d’Anthem, le lancement surprise d’Apex Legends et le lancement prochain de The Division 2, le début de l’année 2019 est empilé avec de gros jeux en ligne. Comme l’a démontré le dernier né de BioWare, et d’innombrables jeux avant lui, les jeux multijoueurs de cette envergure se lancent rarement dans un état brillant. Il semble que tous les jeux en ligne connaissent des problèmes techniques lors de leur lancement, qu’ils soient mineurs, comme les bugs de la première semaine d’Apex Legends, ou qu’ils brisent le jeu, comme les problèmes de connexion qui ont initialement paralysé Diablo 3.

Depuis que les jeux en ligne existent, il y a toujours eu des lancements difficiles, mais on a l’impression que la conversation autour des problèmes de lancement n’a pas vraiment évolué. Les mêmes questions reviennent à chaque fois. Pourquoi cela s’est-il produit ? Pourquoi les développeurs n’ont-ils pas anticipé ce problème ? Pourquoi la correction a-t-elle pris autant de temps ? Avec la sortie rapprochée de tant de grands jeux en ligne et la montée en puissance des jeux en tant que service dans l’industrie, le moment semblait bien choisi pour poser certaines de ces questions aux développeurs dans l’espoir de démystifier le redoutable temps d’arrêt du jour du lancement. Pourquoi rencontrons-nous toujours les mêmes problèmes lors du lancement des jeux, et comment les développeurs les gèrent-ils ?

« La capacité est très rarement le problème »

Lorsque les jeux ne fonctionnent pas ou sont lents à se connecter, beaucoup pensent que c’est parce qu’il n’y a plus d’espace sur le serveur. Les développeurs ont sous-estimé le nombre de joueurs qui se connecteraient et, par conséquent, leurs serveurs ont plié sous la pression. Dans ce cas, tout ce qu’ils ont à faire, c’est de payer pour plus de serveurs, n’est-ce pas ? Eh bien, non, pas nécessairement ; comme c’est souvent le cas lors de la création de jeux, ce n’est pas si simple.

« L’une des mentalités que l’on retrouve souvent en ligne est la suivante : « Pourquoi l’entreprise A n’a-t-elle pas plus de serveurs ? Alex Mann, responsable du développement et ancien analyste de l’assurance qualité chez EA, nous explique. « C’est au moment du lancement que l’on observe le plus de trafic sur ces jeux. Tout le monde a été excité, l’équipe marketing a bien fait son travail, tout le monde est impatient d’être en ligne, et dès que le jeu est lancé, tout le monde clique sur ‘Go’. Mais vous remarquerez que le cycle de vie de la plupart des jeux est marqué par une explosion massive, suivie d’un déclin. Si toutes les sociétés de jeux achetaient le matériel nécessaire pour couvrir tous leurs besoins pendant cette période initiale, deux semaines plus tard, 50 % de leur matériel resterait inutilisé.

« Il ne s’agit pas d’injecter beaucoup d’argent dans un projet pour le rendre plus grand ».

Il est donc difficile pour les développeurs de préparer le lancement sans dépenser trop d’argent et sans acheter trop de serveurs. Heureusement, les développeurs ont désormais accès à des serveurs virtuels par l’intermédiaire d’entreprises comme Amazon Web Services, qui peuvent être activés ou désactivés selon les besoins. Ces types de serveurs sont également devenus nécessaires lorsque les jeux se sont éloignés des connexions peer-to-peer – le type de connexion qui soutenait des jeux comme Halo 2 en 2004 – pour passer à des serveurs dédiés qui soutiennent des jeux massifs et persistants comme Destiny 2 et Anthem. Cependant, les serveurs virtuels ne sont pas un remède miracle, et ils ont leurs propres problèmes.

« La capacité n’est pas nécessairement liée au nombre de serveurs », précise M. Mann. « Même si nous attendons des millions de joueurs et que nous avons les serveurs, nous ne nous attendons pas à ce qu’ils se connectent tous en même temps au portail de connexion. C’est comme s’il y avait suffisamment de voies sur l’autoroute pour que les gens puissent passer. Vous avez deux pays reliés par un pont, et les deux pays disposent de beaucoup d’espace, mais pour passer du pays du client au pays du serveur, quelle est la taille de ce pont ? Il ne s’agit pas d’investir beaucoup d’argent pour le rendre plus grand. En fin de compte, il s’agit souvent d’un goulot d’étranglement lié à la technologie et au moteur utilisés.

L’une des idées fausses que M. Mann rencontre souvent a trait au fonctionnement des équipes de développement – en particulier, l’idée que n’importe qui peut réparer n’importe quoi.

« Lorsque vous avez affaire à des bases de code complexes couvrant plusieurs fichiers construits par 200 personnes, si je regarde mes codeurs et qu’ils ont construit ceci, le codeur A ne connaît pas l’ensemble du projet », explique-t-il. « Il y a ce concept selon lequel tout le monde sait tout sur le code du jeu, alors que l’artiste de niveau devrait aider à fixer l’architecture du niveau. Vous savez, les gestionnaires de communauté ne corrigent pas les bogues.

C’est ce que m’a dit Fredrik Brönjemark, directeur des services en direct chez Massive Entertainment, le studio à l’origine de The Division. « Les grands jeux en ligne sont des logiciels extrêmement complexes, qui s’appuient sur une infrastructure de serveurs en ligne massive », explique Brönjemark. « En plus de cela, il y a une couche supplémentaire de services de première partie, donc il y a beaucoup de façons différentes pour que les choses tournent mal ! Pour The Division, les principaux types d’incidents susceptibles de provoquer des temps d’arrêt ou des problèmes de connectivité étaient l’instabilité du logiciel de jeu fonctionnant sur les serveurs ou des problèmes liés à l’hébergeur. Il est très rare que la capacité des serveurs soit insuffisante. Sur The Division 2, nos serveurs s’adaptent automatiquement en fonction du nombre de joueurs souhaitant jouer au jeu.

Un certain nombre de choses peuvent mal tourner le jour du lancement, et la plupart du temps, le nombre de joueurs est relativement peu important sur la liste de surveillance. Il peut s’agir d’une fuite de mémoire, d’une ligne de code incorrecte unique mais catastrophique, ou d’un point de décalage enfoui quelque part dans l’énorme pipeline du serveur. Un jeu peut avoir un problème avec un certain fournisseur d’accès ou, comme l’a mentionné Brönjemark, les services de première partie sur lesquels un jeu s’appuie peuvent tomber en panne. Le problème peut se situer n’importe où, mais peu importe où il se trouve, c’est le problème de tout le monde. Personne n’est isolé lorsqu’il s’agit de jeux en ligne, ce qui peut rendre la réponse aux problèmes incroyablement difficile et longue.

« Chaque lancement est différent

Tous les développeurs avec lesquels je me suis entretenu ont décrit un processus de triage similaire pour la résolution des problèmes. Mann a donné un aperçu de ce à quoi peut ressembler une correction, du début à la fin. Tout d’abord, un développeur doit passer au crible les symptômes du problème pour en identifier la cause réelle. Ensuite, il fait appel aux personnes responsables de cette partie du jeu pour trouver une solution. Peut-il s’agir d’un problème qu’ils peuvent mettre à jour de leur côté ou doivent-ils publier un correctif ? Une fois la solution trouvée, il faudra la tester pour s’assurer qu’elle ne perturbe rien d’autre, surtout s’il s’agit d’un correctif.

« Il y a un contrôle avant que quoi que ce soit ne soit mis en ligne », explique M. Mann. « Il y a beaucoup d’échanges avec les détenteurs de plates-formes [comme Sony et Microsoft] pour s’assurer que nous travaillons ensemble à la réussite du jeu ; nous devons passer par des étapes d’assurance qualité. Nous devons passer par des étapes d’assurance qualité. Et pendant que nous appliquons ce correctif, si nous réagissons par réflexe et que nous corrigeons ceci maintenant, mais qu’une demi-heure plus tard nous devons appliquer un second correctif dans la même journée, ce sera un vrai gâchis. Nous devons donc nous dire : « Nous faisons ce correctif ; quels autres problèmes critiques pouvons-nous résoudre dans le cadre de ce correctif ? Quels sont les autres problèmes ? On ne peut pas faire un correctif en une demi-heure. Il faut s’assurer d’être intelligent dans la manière dont on corrige ce contenu ».

Une fois que tout cela est fait, si l’univers le permet, les développeurs peuvent faire passer le correctif et commencer à le surveiller et à communiquer ses effets sur leurs canaux sociaux. Mais « il n’y a pas de délai d’une demi-heure », précise Mann, ajoutant qu' »il y a peut-être des centaines de personnes qui toucheront le patch avant qu’il ne soit diffusé ».

Frank Sanchez, ancien représentant de la communauté de BioWare et de Gazillion Entertainment avec une expérience en ingénierie, connaît bien ce paradigme. Ayant passé beaucoup de temps à rassembler les réponses et à rédiger des notes de correctifs, il a vu les deux côtés du processus de mise à jour, depuis les commentaires des joueurs jusqu’à la soumission des correctifs. Il sait également mieux que quiconque à quel point les correctifs peuvent être compliqués et à quel point les problèmes de lancement peuvent être frustrants pour les joueurs comme pour les développeurs.

« Nous sommes les derniers à vouloir qu’un serveur soit mis en place et que deux heures plus tard, le lag soit si important que les gens ne puissent pas se connecter », explique Sanchez. « Je vous garantis que si [les développeurs] mettent en place un serveur pour une version bêta et qu’il ne fonctionne pas correctement, c’est probablement parce que quelqu’un a passé du temps en plus de ce qu’il faisait déjà pour le mettre en état de fonctionner. Ainsi, lorsque quelqu’un en ligne dit « Eh bien, ils sont juste paresseux », c’est complètement faux et flagrant. Le travail est fait, le défi consiste à répondre aux problèmes et à communiquer avec les joueurs lorsqu’ils surviennent. C’est une science imparfaite… chaque lancement est différent. Même si deux jeux sont développés sur Unity ou autre, même si le genre est le même, le processus est différent. On ne peut pas dire ‘Ce jeu était bien, quel est le problème avec ce jeu’, parce que chaque jeu est unique ».

Vous ne pouvez pas dire « Ce jeu était bien, quel est le problème avec ce jeu », parce que chaque jeu est unique.

Les commentaires de M. Sanchez portent sur une autre question qui revient souvent au moment du lancement : pourquoi n’avez-vous pas anticipé ce problème ? Le jeu X a peut-être rencontré des problèmes il y a quelques mois. Les développeurs du jeu Y ont certainement pu s’en rendre compte et prendre des mesures pour éviter ces mêmes problèmes, n’est-ce pas ?

Au-delà des différences entre les jeux, toutes les personnes à qui j’ai parlé m’ont dit qu’il était impossible d’anticiper certains problèmes. Les tests internes sont limités et ne peuvent jamais être comparés au lancement réel d’un jeu.

« Il n’y a tout simplement pas de simulation pour le direct.

« On ne peut pas planifier pour des joueurs simultanés en direct », poursuit M. Sanchez. « C’est tout simplement impossible. Il n’y a pas de substitut. J’ai vu toutes les méthodes de test de résistance en interne avant de lancer un jeu, et il n’y a tout simplement pas de simulation pour le jeu en direct. »

C’est là que les tests de stress et les périodes bêta de pré-lancement entrent en jeu. Ils ne sont pas parfaits, mais ils constituent le meilleur moyen d’évaluer l’aspect du lancement d’un jeu et de déterminer ce qui doit être corrigé avant le prime time. « Les bêtas sont extrêmement utiles », explique M. Mann. « Il est impossible d’obtenir en interne la taille et l’échelle d’un test bêta. Vous ne pouvez tout simplement pas embaucher autant de personnes pour tester vos serveurs. La meilleure façon de tester en direct est d’être en direct. Si vous regardez beaucoup d’alphas et de bêtas, il y a ce concept qu’il n’y a pas assez de serveurs, qu’il y a des bogues et d’autres problèmes, mais au bout d’une semaine, ils ont trié et la dernière version ou la version finale n’a pas ces problèmes. C’est uniquement parce qu’ils ont été expérimentés [en direct] et étudiés au cours de ces bêtas ».

« Récemment, un studio a lancé une version bêta de son jeu et plusieurs de mes amis se sont précipités pour jouer, mais ils sont tombés sur un bug qui les a bloqués dans le tutoriel parce qu’un objet clé n’était pas apparu sur le serveur », me raconte Mann, en soulignant à quel point il peut être difficile d’anticiper les défauts lors du lancement d’un jeu en ligne. « Je vous garantis que lors de tous les tests d’assurance qualité effectués sur ce jeu, cet objet a toujours été présent. Le seul moyen de le découvrir est de tester ce flux à grande échelle. Je soupçonne que ces personnes en sont maintenant bien conscientes et qu’elles s’efforcent de résoudre ce problème avant le lancement, tout cela grâce à ce travail de bêta.

On ne peut pas tout réparer

Si les bêtas sont si formidables, pourquoi les développeurs n’en organisent-ils pas davantage, et pourquoi ne les organisent-ils pas des mois avant le lancement ? Comme c’est souvent le cas dans les jeux, la technologie et le temps ne permettent pas toujours aux développeurs de faire exactement ce qu’ils veulent. En raison de la façon dont la plupart des jeux sont conçus, ils ne se mettent en place qu’à la toute fin, ce qui explique généralement pourquoi les bêtas apparaissent si peu de temps avant le lancement. Et quels que soient les enseignements que les développeurs tirent d’une bêta, quels que soient les problèmes qu’elle révèle, ils ne peuvent pas, de manière réaliste, retarder leur jeu en conséquence. Un fournisseur de services web ne veut pas qu’une équipe manque la date de démarrage de son serveur, pas plus qu’un éditeur ne veut manquer sa date de lancement. C’est pourquoi, tout comme certains problèmes ne peuvent être anticipés, certains bogues ne peuvent tout simplement pas être corrigés à temps pour le lancement.

Le programme de la bêta de Division 2 était assez complet, avec des bêtas privées et ouvertes, ainsi qu’un test de stress plus ciblé. Ce n’est pas le cas de tous les jeux, mais ceux qui y parviennent bénéficient grandement de ce que Brönjemark appelle la « répétition finale ». La première bêta ouverte est prévue du 1er au 4 mars, deux semaines avant le lancement.

« J’adorerais livrer un produit sans bogues », déclare M. Sanchez, un commentaire que vous entendrez de la bouche de tout développeur qui a traversé l’enfer pour livrer un produit. « Mais n’importe quelle équipe vous dira que c’est très difficile à réaliser. C’est la réalité. La liste des éléments à corriger évolue sans cesse. Vous devez comprendre que lorsqu’il s’agit de bogues, il y a des bogues qui sont potentiellement expédiés et d’autres qui sont découverts après le lancement. Tout cela doit être priorisé, planifié et discuté. C’est le triage. Les lancements les plus chanceux sont ceux qui comportent des bogues, mais pas de bogues rédhibitoires.

En outre, la création d’une version bêta peut être une tâche longue et laborieuse. Les développeurs ne peuvent pas simplement découper un morceau de leur jeu et le télécharger sur Xbox Live ou le PlayStation Network. Les bêtas sont souvent développées séparément du jeu (mais en tandem), ce qui prend plus de temps et d’argent. C’est pourquoi des problèmes qui ont été corrigés depuis longtemps dans la version principale d’un jeu peuvent encore être présents dans sa version bêta. Nous l’avons vu dans les démos d’Anthem et dans la dernière bêta de The Division 2, par exemple.

« J’entends souvent les gens dire qu’ils pensent que les tests bêta ne sont que des campagnes de marketing, et que les développeurs ne peuvent rien en tirer puisque le jeu est déjà terminé à ce moment-là », me dit Brönjemark. « J’aimerais dissiper ce mythe. Même lorsque le jeu est déjà imprimé sur disque et que le premier patch est déjà prêt, il y a encore énormément de choses que nous pouvons corriger côté serveur, à la fois en termes de technologie, mais aussi en termes de gameplay et d’équilibrage.

En revanche, explique M. Sanchez, « les calendriers d’édition et de développement des jeux sont très agressifs, parfois trop. Quand un jeu doit-il être expédié, combien de fonds vous reste-t-il, depuis combien de temps êtes-vous en train de le développer ? Parfois, le succès d’un lancement dépend vraiment du nombre de fois où vous avez dû repousser vos jalons, du nombre de fois où vous avez retardé votre lancement parce que vous aviez quelque chose à peaufiner. Certains jeux ne peuvent être livrés qu’avec un certain degré de peaufinage. Vous ne pouvez pas dire qu’il est totalement parfait une fois qu’il a été lancé. Dans certains cas, un jeu sera livré dans un état prêt à être lancé, mais il y aura peut-être un peu de peaufinage à faire ».

Un lancement, c’est plus qu’un jour

Les développeurs et les joueurs veulent tous deux que leurs jeux fonctionnent parfaitement la première fois qu’ils les lancent, mais la réalité du développement de jeux est qu’il y a tellement de pièces mobiles et tellement de limites inamovibles que certains problèmes vont forcément passer à travers les mailles du filet, et les chances que cela se produise ne font qu’augmenter à mesure que les jeux deviennent de plus en plus gros. Sanchez estime que c’est la raison pour laquelle nous devons considérer les lancements de ce type de manière globale. Les performances d’un jeu le jour de son lancement sont importantes, mais ce n’est pas tout.

« Ce ne sont pas les problèmes qui importent, car il y en aura toujours », explique M. Sanchez. « Ce qui compte, c’est la façon dont vous abordez ces problèmes. Si vous êtes lents, si vous ne les traitez pas correctement ou si vous êtes hostiles à vos joueurs, ils ne s’en remettront pas. S’il y a une chose que j’aimerais que les joueurs comprennent, c’est que les problèmes surviennent, quelle que soit la qualité de la planification. Vous devriez tenir les développeurs responsables de la façon dont ils réagissent. Si vous rencontrez un problème une semaine après le lancement, mettez-les au pied du mur et dites-leur : « Je n’ai pas une bonne expérience, voici pourquoi, je m’inquiète que ces problèmes ne soient pas résolus ». C’est de cela que nous voulons entendre parler ».

Les problèmes surviennent, quelle que soit la qualité de la planification.

Aucun jeu ne se lance parfaitement. Cela n’arrive tout simplement pas. Comme le dit Sanchez, « tout ce que vous considéreriez comme un lancement en douceur est simplement quelque chose qui n’a jamais atteint le niveau où un joueur a perçu que quelque chose n’allait pas ». Il y a toujours des cafouillages en coulisses. Mann a décrit cette situation comme celle d’un groupe de développeurs réunis dans une « salle de guerre » et surveillant un mur d’écrans pour détecter les retours d’information et les problèmes potentiels. Parfois, ces problèmes sont détectés rapidement, parfois ils n’apparaissent que quelques heures plus tard, et parfois ils ne peuvent être résolus que quelques heures ou même quelques jours plus tard.

Le fait est que les jeux en ligne massifs auront toujours des problèmes techniques au lancement. D’ailleurs, tous les jeux modernes ont des problèmes au lancement. C’est la nature même de la technologie et de l’industrie d’aujourd’hui. Cela ne signifie pas que les joueurs doivent donner aveuglément leur feu vert aux jeux qui sortent avec des problèmes de conception catastrophiques ou autres, mais cela permet de relativiser le lancement moyen. Un jeu peut présenter des problèmes mineurs que nous ne remarquons même pas, ou des problèmes qui brisent manifestement le jeu. Quoi qu’il en soit, tout ce que l’on peut faire, c’est espérer le meilleur, se préparer au pire et signaler les problèmes lorsqu’ils font inévitablement surface.