Les refontes s'enchaînent : champions, map, launcher, et bientôt peut-être récapitulatif de mort ? C'est du moins l'hypothèse que suggère Riot. Si le récapitulatif de mort n'est en l'état actuel pas optimal, notamment à cause d'un certain nombre de bugs, il serait plus simple de le refaire à zéro que de l'améliorer. Mais tout cela reste encore de l'ordre de l'hypothétique.
Les Nomerables sur Vers une update du Récapitulatif de mort ? (Traduction - Source)
C'est une question épineuse, et tout dépend de ce que vous entendez par « update ».
Si vous parlez de la multitude de bugs, alors cela va prendre du temps et pourrait ne pas valoir le coup. Nous devons plutôt revenir en arrière et évaluer de nouveau ce qui fait qu'un tableau récapitulatif de mort est complet. Nous ne voulons pas nous lancer dans une histoire de journal de bord : les informations brutes sont rarement concrètes. De même, je ne suis pas sûr de savoir dans quelle mesure le système existant est utile en dehors de vous faire savoir combien de dégâts physiques ou magiques vous avez reçu. Nous allons probablement à un moment faire évoluer le système, une fois que nous en aurons fini avec certaines fonctionnalités de l'interface utilisateur, mais si nous le faisons, attendez-vous davantage à une refonte du système plus qu'à une simple mise à jour.
Pour faire un parallèle avec l'architecture, imaginez une demeure complexe, construite sur des fondations de faible qualité, ce qui induit donc des problèmes structurels. Les citoyens trouvent cela disgracieux, mais ils admettent tout de même que la propriété a de la valeur. La ville n'a que peu de solutions à sa portée pour résoudre le problème :
A - Construire une belle façade pour cacher les problèmes.
B - Reconstruire minutieusement les fondations, pièce par pièce, sans toucher au reste.
C - Démolir et reconstruire à partir de zéro.
Bon, nous sommes plus ou moins certains de vouloir un jour appliquer l'option C. Cela rend donc les options A et B moins attirantes. Mais il y a aussi d'autres façons d'utiliser ces ressources, comme construire cette nouvelle école élémentaire, ou nettoyer le parc, etc.
Voilà la situation dans laquelle nous nous trouvons actuellement - les bugs sont profondément ancrés. À quel point ? Nous avons à plusieurs reprises tenté de résoudre ces problèmes, mais en vain. Nous devons évaluer la priorité de ce travail par rapport à toutes les autres choses que nous faisons actuellement, et en calculer ainsi la valeur. Peut-être vous partagerais-je certains de nos concepts vis à vis du possible fonctionnement du récapitulatif de mort à l'avenir. Nous y pensons clairement !
Vous faites la supposition que les options B et C sont équivalentes. Ce n'est pas le cas : dans l'exemple de la restauration d'une demeure comme dans le cas de la correction du code lié au récapitulatif de mort, l'option C est en réalité bien plus simple que l'option B.
La différence de ressources fonctionnelles à fournir entre l'option B et l'option C se caractérise plutôt par le fait qu'il y ait beaucoup d'autres pièces à traiter, comme le Game Design, l'UX Design, le Visual Design, etc. Je rencontre aussi régulièrement des débats sur « Pourquoi n'avez-vous pas corrigé tel ou tel bug ? ». Certains bugs sont simples, d'autres sont plus complexes. Je crois par exemple que le cas de Shen vient à peine d'être corrigé en interne par un de nos supers ingénieurs gameplay, et de ce que j'en ai compris, la tâche a été très compliquée. Il y a beaucoup de choses à prendre en compte pour juger de la difficulté de la résolution d'un bug et de la priorité de ce bug. Bien sûr que nous aimerions pouvoir corriger tous les bugs possibles, mais cela n'est pas une ambition réaliste au vu de la quantité de contenu que nous proposons déjà et que nous continuons d'enrichir.
Dans quelle mesure le bug se révèle-t-il pénalisant pour le joueur ? L'échelle va d'une simple gêne à un problème rendant le jeu injouable.
Dans quelle mesure le bug est-il reproduisible ? Si comme dans le cas de Shen, le bug ne se produit que dans une game sur cent et ne répond pas à un processus précis connu, il est alors très difficile d'en suivre l'évolution.
Dans quelle mesure le bug est-il profondément ancré ? Corriger un problème de petite ampleur peut avoir des conséquences bien plus importantes, comme causer un problème sur quelque chose qui semblait sans rapport, quelque chose qui pourrait par exemple dépendre du bug car un autre développeur aurait supposé que le bug était une caractéristique voulue.
Combien de temps la résolution de ce bug va-t-elle demander ? Mon équipe (l'équipe liée à la clarté) dispose de deux ingénieurs - en perdre un au profit d'une course à la résolution de bugs pourrait être désastreux pour le respect de nos délais de livraison de contenu si cela signifie que les autres membres de notre équipe se retrouvent paralysés.
Dans le cas du récapitulatif de mort, nous avons la combinaison d'une faible gêne pour le joueur (l'exactitude du chiffrage des dégâts individuels n'est pas importante lorsqu'il s'agit de fournir des informations concrètes), d'une compréhension réduite du processus de reproduction du bug (Pourquoi indique-t-il parfois que l'aura de la Dominion inflige des dégâts ? Personne ne sait !), d'un bug dont la source est très profonde, et de délais très importants quant à sa résolution. Entre parenthèses, je pense que nous traînons parfois un peu des pieds avec certaines fonctionnalités, mais c'est un point sur lequel nous essayons de nous améliorer.
Quelques remarques concernant votre proposition :
Cela correspond davantage à l'approche « journal de bord » du combat ou de la mort, ce qui est selon moi moins convaincant dans la mesure où cela ne fournit pas d'informations concrètes. Les joueurs qui meurent ont généralement besoin que le tableau ne leur fournisse qu'une seule information, à savoir le « pourquoi » de leur mort. Malheureusement, le « pourquoi » n'est jamais une réponse simple, donc la plupart des joueurs ne voient pas d'inconvénient à extraire le « pourquoi » du « comment ». Les journaux de bord de combat indiquent le « comment », mais pas le « pourquoi ». Si nous devions revoir la conception de ce système, nous pencherions davantage vers le « pourquoi ».
