Carnet de développement n°57 : La Vie d'un Bug
Bon après-midi, tout le monde. Je suis Magne 'Meneth' Skjæran, le programmeur de CK2. Par le passé, j'ai écrit des carnets de développement sur le modding, l'optimisation, l'ergonomie et celui de la semaine dernière qui expliquait le rôle et les responsabilités des différentes membres de l'équipe de développement.

L'été se poursuit, et les bureaux resteront assez vides jusqu'à fin juillet, y compris en ce qui concerne l'essentiel de l'équipe de CK2. Mais, comme on dit, the show must go on, et pour les quatre semaines à venir, c'est moi qui écrirai tous - ou presque - les carnets de CK2.

Puisque la majeure partie de l'équipe est en vacances, le travail avance peu, ce qui signifie que nos quatre carnets seront assez légers en termes d'infos sur l'extension et le patch à venir, mais j'espère parvenir tout de même à les rendre intéressants en partageant avec vous des réflexions et des informations croustillantes.

Aujourd'hui, je vous parlerai de la vie d'un bug. Il s'agira essentiellement d'une description de la trajectoire d'un bug de sa découverte à la mise en place de la correction, sans oublier les acteurs impliqués.

A la fin de ce carnet, je partagerai avec vous cinq ajouts du patch 2.8 choisis au hasard.

Le Bug
Afin d'illustrer le processus, j'utiliserai le bug suivant dans une sorte d'étude de cas :
- Correction d'un bug où les prêtres de religions où les prêtres ne sont pas censés pouvoir se marier se mariaient ou se fiançaient

Cette correction fait partie du patch 2.7.1. En quelques lignes, il s'agissait de corriger un bug où le Pape finissait avec un membre de sa famille tellement accroc aux mariages de Sang Divin qu'ils se fiançaient au Pape, quand bien même il n'en avait pas le droit. Le Khvedodah (ndt : ou "Khvaetvadatha", le mariage incestueux tel qu'il aurait été pratiqué par les nobles zoroastriens) est une chose merveilleuse, mais il se terminait toujours dans les larmes : au moment où la nièce du Pape arrivait en âge de se marier, les fiançailles étaient rompues.

Rétrospectivement, cette entrée du changelog aurait dû être "Correction d'un bug où le Pape aimait tellement le Khvedodah qu'il se fiançait même s'il ne lui était pas permis de se marier." On en apprend tous les jours.

La Découverte
Ce bug a été découvert par l'un de nos bêta-testeurs le 12 février 2017 alors qu'il jouait au jeu ; il a remarqué que le Pape se mariait matrilinéairement à sa nièce, et il nous a transmis une sauvegarde où ce bug se répétait sans cesse.

La découverte d'un bug par un bêta-testeur n'est que l'une des nombreuses voies vers la découverte d'un bug.
Playtest : Les testeurs du service de l'assurance-qualité passent du temps à jouer au jeu, tout simplement, même si la plupart du temps ils se focalisent sur les nouveautés. Par exemple, pendant le développement de Monks and Mystics, ils se concentraient sur des sociétés spécifiques. Pendant les tests, ils nous signalaient les bugs qu'ils rencontraient, ainsi que les problèmes d'équilibrage, d'ergonomie, etc. En fonction du stade de développement, ces problèmes peuvent également être transmis directement ; si le système est encore en cours de développement, une simple remarque au développeur responsable peut suffire, mais s'il est censé être terminé, un signalement dans les formes est généralement produit.

Vérification des tâches : Quand une tâche (par exemple : "ajouter une action de gestion de l'ensemble des prisonniers") est terminée, l'assurance-qualité vérifie si tout fonctionne comme indiqué. S'ils identifient des problèmes dans cet intervalle, soit on relancera le développement de cette tâche, soit ils feront un signalement de bug. Vous pourrez en lire davantage à ce sujet dans la section "Vérification" de ce carnet.

Autres développeurs : Les développeurs qui ne font pas partie de l'Assurance-Qualité jouent également au jeu, et ils sont supposés signaler tous les bugs qu'ils rencontrent, même si les trouver n'est pas leur objectif principal.

Surveillance du forum : Alors que les autres méthodes de détection des bugs sont concentrées sur les problèmes rencontrés avant la publication d'un patch, certaines choses peuvent échapper à notre attention. Dans ce cas, elles seront souvent découvertes par des joueurs, et certains d'entre eux signaleront les bugs sur les forums, sur reddit, ou d'autres communautés en ligne. L'assurance-qualité passe une partie de son temps à les consulter, et à tenter de reproduire les bugs décrits afin de produire les signalements dans les formes en interne. Si un bug ne peut pas être reproduit avec les informations fournies, ils demanderont généralement plus d'informations. Un signalement de bug ne peut être réalisé que si le problème peut être reproduit, ou si beaucoup de joueurs le rencontrent. Si vous voulez nous signaler un bug, mettez toutes les chances de votre côté en décrivant toutes les étapes permettant de reproduire le bug, et envoyez une sauvegarde quand cela est possible !

Il y a également plusieurs manières de découvrir un bug, mais ces quatre méthodes et le bêta-test englobent la majorité des cas.

Signalement
Une fois qu'un bug a été découvert, il soit être signalé en interne. Notre base de données de bug est inclue dans l'application web de gestion de projet Jira, qui nous donne accès à tout un panel de moyens pour gérer facilement les problèmes rencontrés afin de les traiter en temps et en heure sans être ignorés.
signalement d un bug sur ck2

Ci-dessous, vous pouvez voir le signalement du bug des fiançailles du Pape.

Les éléments principaux nécessaires au signalement sont :

Titre : Un titre qui résume le problème. Il doit suivre le format : Projet - Extension - Zone d'effet - Description du problème. Dans le cas présent, "CK2 - MnM - IA - Le Pape se fiance matrilinéairement à la fille d'un roi de sa famille." Le titre doit être aussi clair que possible sur la nature et les circonstances du problèmes.

Description : La description doit comprendre tout ce qui ne tient pas dans le titre. Cela inclut souvent une description des actions du joueur avant de rencontrer le bug, des théories sur ses causes, ou, dans le cas de bugs découverts en surveillant les forums, la source du signalement.

Étapes pour la reproduction : Par certains aspects la section la plus importante, les étapes nécessaires à la reproduction énoncent la manière dont il est possible de reproduire le bug. Sans elles, la plupart des bugs seraient impossibles à corriger, car savoir que quelque chose peut se produire ne signifie pas que l'on peut deviner comment elle se produit. Cette section est utilisée à la fois par la personne qui corrigera le problème (voir "Correction") et celle qui vérifiera cette correction (voir "Vérification").

Résultat : Les signalements comprennent également à la fois le résultat attendu et le résultat obtenu, afin de rendre plus clair encore la nature exacte du problème. La plupart du temps, cela est relativement évident, mais pour des questions d'équilibrage, cette section est particulièrement utile. Cela permet également de savoir plus facilement si un problème peut être résolu ou non (voir "Vérification").

Pièces jointes : Souvent une capture d'écran. Une sauvegarde est également ajoutée si cela facilite la reproduction du problème. Pour les crashs et autres problèmes similaires, les logs sont également inclus, de même que le crash dump qui peut être utilisé par le programmeur pour voir à quel niveau du code le jeu a crashé.

Il y a encore d'autres champs à remplir, mais ils sont généralement utilisés à des étapes plus tardives du processus.

Attribution
Une fois qu'un bug est signalé, il faut décider qui sera responsable de la correction, l'importance de cette correction, et sa planification. L'attribution est d'abord décidée par spécialité ; un bug sera catégorisé dans Script, Code, ou Art, en fonction de ses causes. Cette attribution est généralement faite par les testeurs de l'assurance-qualité si elle n'aura pas déjà été faite au moment de la création du signalement.

L'ordre de priorités est établi en fonction de l'importance de la correction, et s'échelonne de 0 (Doit être corrigé immédiatement) à 5 (Non prioritaire). Un crash, par exemple, sera une priorité 1 - Doit être corrigé, tandis que le big de fiançailles du Pape est simplement une priorité 3 - Moyenne. Le chef de projet a le dernier mot en matière de priorités, mais en général, c'est l'assurance qualité qui décide de la priorité des bugs, tandis que le chef de projet s'occupe de planifier les tâches à accomplir.

De manière similaire, il y a la Sévérité, qui s'échelonne de Très Élevée à Aucune. Plutôt que de signaler l'importance de la correction du bug, cela représente à quel point il sera difficile à corriger. Les deux sont liés, mais il est possible de rencontrer une erreur d'écriture à haute priorité qui sera d'une sévérité mineure. Le degré de sévérité est décidé par l'AQ plutôt que par le chef de projet.

Ensuite, il faut décider si le bug doit être corrigé. L'attribution a lieu pendant un sprint (une période pendant laquelle un certain nombre de tâches doit être accompli. Sur CK2, ces périodes durent 4 semaines). Les bugs plus graves sont généralement assignés alors qu'un sprint est encore en cours, tandis que les moins sérieux sont reportés aux semaines consacrées aux éléments de développement mineurs. Les bugs liés aux nouvelles fonctionnalités font exception ; ils sont presque toujours assignés au sprint en cours même s'ils ne sont pas particulièrement graves. C'est parce qu'il est important de s'assurer que nous n'introduisons pas plus de bugs que nous n'en corrigeons. Cependant, les bugs plus anciens sont toujours traités pendant les semaines de peaufinage, une fois que l'extension elle-même est terminée. Pendant les sprints, la dernière des quatre semaines est dédiée à la correction de bugs ; pendant les trois premières semaines, seuls les bugs qui empêchent de travailler sur autre chose sont corrigés.

Une fois qu'un sprint est terminé, les bugs produits pendant ce sprint sont attribués à une personne spécifique. Le chef de projet a une certaine responsabilité à ce niveau, mais celle-ci est souvent déléguée au chef de la spécialité concernée.

Correction
Les problèmes plus importants du sprint ont tous été résolus, il est donc temps de corriger notre bug. L'individu chargé de ce bug appuiera donc sur le bouton "Commencer le processus", informant par le fait le reste de l'équipe que le travail est en cours.

Le responsable du bug va ensuite examiner les étapes nécessaires à sa reproduction, et tenter de comprendre ce qui ne va pas. Dans le cas des fiançailles du Pape, j'étais chargé du bug, et j'ai pu reproduire le bug sans problème. Cela m'a permis d'établir le "point de rupture" dans le code de l'IA pour le mariage, qui ignorait le code qui devait empêcher le Pape de se fiancer. Cela m'a permis de chercher dans le code les conditions qui définissent les conditions pour le mariage dans les théocraties. J'ai fini par découvrir que la fonction "CanMarry" n'était jamais vérifiée pour notre exemple, et que c'était seulement le cas dans l'interaction de mariage. Ainsi, les fiançailles pouvaient toujours avoir lieu, et n'étaient invalidés que lorsque les personnages arrivaient en âge de se marier.

Le résultat final fut une nouvelle ligne de code dans la fonction CCharacter::CanMarry :
Code:
if ( ( GetGovernment()->IsTheocracy() && !GetReligion()->CanPriestsMarry() ) || ( pCharacter->GetGovernment()->IsTheocracy() && !pCharacter->GetReligion()->CanPriestsMarry() ) )
        return false;
Cela permet de vérifier si un personnage est un théocrate appartenant à une religion qui ne permet pas aux prêtres de se marier.

Après avoir recompilé le jeu, j'ai tenté de reproduire les étapes conduisant au bug, et j'ai constaté que le Pape ne se fiançait plus.

Une fois la correction effectuée, une entrée est ajoutée au changelog. La correction et l'entrée sont ensuite ajoutés dans notre répertoire pour le jeu. Nos serveurs compilent le jeu, et quelques heures après minuit une nouvelle version est mise en ligne sur steam afin que nos bêta-testeurs puissent jouer.

Le bug est ensuite marqué comme résolu avec un message résumant les opérations effectuées, et dans quelle révision du jeu le changement a été effectué. Dans notre cas, il a été marqué comme résolu 6 jours après son signalement, mais ce délai peut facilement s'étaler de quelques minutes à plusieurs mois.

Vérification
Ensuite, l'assurance-qualité vérifie que le bug est vraiment corrigé, et qu'aucun nouveau problème n'a surgi en conséquence de la correction.

Le processus consiste à suivre les étapes de reproduction du bug pour voir si le problème a bien disparu, et si ce dernier est particulièrement complexe, à tester d'autres manières de reproduire le bug.

Comme je l'ai écrit dans la section "Découverte", l'assurance-qualité s'occupe également de découvrir de nouveaux bugs, ce qui inclut les bugs apparaissant en tant qu'effets secondaires de la correction d'autres bugs.

Quand l'AQ est satisfaite, ils notent le problème comme étant résolu, et le processus de correction est terminé. Si le bug persiste sous une forme ou une autre, le signalement est relancé à l'étape "Correction".

Parfois, des bug réapparaissent après correction. Dans ce cas, la correction reprend également.

Dans le cas des fiançailles du Pape, le bug a été vérifié 45 jours après sa résolution. Nous essayons d'éviter que la vérification prenne plus d'un sprint de retard sur la correction, car il est généralement plus facile de retourner à une correction quand elle est encore fraîche.

Publication
Le bug est maintenant corrigé, il est temps de sortir un patch, mais le processus n'est pas encore terminé.

Bien que la correction de notre bug spécifique ait été vérifiée, le projet en tant que tout doit encore passer par une dernière étape avant la sortie : l'essai de fumée.

L'essai de fumée sert essentiellement à vérifier qu'il n'y a rien de terriblement cassé dans les trois systèmes d'exploitation que nous supportons : Windows, Mac et Linux. Contrairement aux autres étapes du processus, l'essai de fumée n'est pas effectué par l'équipe de CK2, mais par l'équipe d'AQ central de Paradox Studios.

Une fois que l'AQ centrale a validé la publication, aucun nouveau changement ne peut être effectué. Plusieurs jours ou plusieurs semaines après, le patch est publié, et le bug est corrigé pour tous les joueurs.

Résumé
En somme, nous avons un certain nombre d'étapes qui permettent de s'assurer que les bugs sont découverts, corrigés, et qu'ils restent corrigés. Malgré cela, certains bugs persistent, car CK2 est une machine complexe. Il y a toujours des bugs connus dans chaque patch, car il est impossible de trop retarder leur sortie, et la correction d'un bug peut facilement en causer un autre. Nous essayons de minimiser au maximum le nombre de bugs connus en prenant beaucoup de temps pour peaufiner le jeu avant chaque sortie, et en diminuant le temps imparti exclusivement aux corrections de problèmes critiques. Il y aura toujours des bugs, mais nous travaillons dur pour éviter d'en introduire de nouveaux et pour réduire leur nombre.

J'espère que vous avez trouvé cet aperçu intéressant.

Comme promis, voici cinq entrées du changelog du patch 2.8 :
  • L'IA a appris à écrire correctement, et ne cherchera plus les missions des "soceities" plutôt que des "societies". Grâce à cette nouvelle capacité, l'IA saura mieux identifier les cibles de missions.
  • Correction d'un bug où l'utilisation du soutien du conseil permettait d'éviter d'utiliser une faveur au suzerain
  • Ajout d'un ordre saint pour les Manichéens
  • Les Gardiens peuvent désormais être assignés à la naissance (mais resteront sans effet jusqu'à l'âge de 6 ans)
  • L'IA ne devrait plus tenter de faire des mariages matrilinéaires si ceux-ci ont été désactivés dans les règles du jeu
C'est tout pour cette semaine. La semaine prochaine, nous parlerons des améliorations du modding auxquelles nous avons procédées dans le patch 2.8.
Auteur : Meneth
Traduction : Spectator_Errans