De l’alpha à la bêta : des jalons de production essentiels

Les studios de développement qui collaborent avec des éditeurs sont tenus de suivre un plan de milestone qui démarre dès la livraison du premier prototype jouable et qui s’étend jusqu’à la livraison du master final. Une milestone est un terme technique définissant un jalon de projet, c’est-à-dire une compilation que les équipes fournissent au payeur afin que ce dernier vérifie l’état d’avancement d’une œuvre en fonction du planning instauré. Dans ces jalons, nous retrouvons les célèbres alphas et bêtas. Une alpha est une version fonctionnelle du jeu, qui intègre les fonctionnalités clés. Elle n’est ni stable, ni optimisée graphiquement. La bêta, qui intervient bien plus tard que l’alpha, contient un produit proche du rendu final, même si les bugs sont encore nombreux. “Les dates clés sont décidées au début de la production. Pour une alpha, le rendu est déterminé en fonction du nombre d’assets qu’il y a à produire” nous explique Jérôme Vu Than, qui fut pendant sept années Project Manager chez Quantic Dream avant d’être Senior Producer chez Gameloft. “Par exemple, si pour une animation nous avons besoin de trois jours de travail, et qu’il est prévu de développer trente mille animations dans le jeu, une simple multiplication permet de déduire combien de temps il faut pour couvrir ce besoin par un animateur” ajoute-t-il. Si les milestones sont déterminées en fonction des éléments à confectionner, l’éditeur a également son mot à dire à propos de la fenêtre de sortie du produit final. “Généralement, il donne une date à laquelle il aimerait bien voir le projet disponible dans son portfolio, peut-être parce qu’il voit un creux dans son propre planning de sorties” confirme Jérôme.

En plus des alphas et bêtas en interne, un jeu peut connaître des bêtas publiques.

Ces étapes de développement qui animent en interne la production d’un titre se révèlent angoissantes pour les studios, puisqu’elles peuvent mener à un rejet de la part du payeur. “Le temps de réponse de l’éditeur prend entre une semaine et quinze jours” nous confie l’ancien Senior Producer de Gameloft. “En cas de milestone ratée, les équipes reçoivent une liste détaillée de ce qui ne va pas. Elles disposent alors d’une certaine période, décidée avec l’éditeur, afin de corriger les points indiqués. 'Si après plusieurs essais le résultat ne convient toujours pas au payeur, ce dernier peut tout simplement annuler le développement”'. Ces annulations font les gros titres des sites spécialisés. En 2017, l’annulation de Scalebound par Microsoft a fait grand bruit sur la toile. Depuis, le constructeur américain préfère prendre son temps avant d’annoncer officiellement le développement d’un nouveau projet. “S’il juge que le studio de développement n’a pas réussi à atteindre les objectifs fixés, l’éditeur peut décider de ne payer que partiellement, voire pas du tout, la dernière milestone. Il a ensuite le loisir de se retirer définitivement du projet” prévient Jérôme.

L'annulation de Scalebound repose sûrement sur un niveau de qualité insuffisant.

Le contrôle qualité assure une chasse aux bugs... et à leur reproduction

En première ligne dans la lutte contre les bugs se trouve le département de l’assurance qualité, composée de testeurs QA. Leur rôle est de déceler ce qui ne fonctionne pas dans un titre en cours de production et d’avertir les personnes les plus à mêmes d’arranger les choses. Les équipes de l’assurance qualité sont sous la responsabilité du producteur. Elles établissent les bons processus pour les rapports de bugs. Elles mettent également en place les procédures de tests adaptées à l'état d'avancement du projet. Cela signifie qu’une alpha ne s’évalue pas comme une bêta, et que les soucis rencontrés ne sont pas estimés de la même manière. Les bugs classés “C” ou “D”, c’est-à-dire peu importants ou purement visuels, prennent du galon au fur et à mesure que la date de livraison du master approche. Les bug “A” signifient qu’un problème empêche la progression du joueur et l’oblige ainsi à arrêter le jeu. Ils sont les plus recherchés mais aussi les plus redoutés des bugs.

Les testeurs QA peuvent eux aussi avoir leurs spécialités ou leurs tâches dédiées, comme refaire chaque jour la totalité d’une aventure pour s’assurer que l’enchaînement des niveaux est le bon. Les problèmes rencontrés sont envoyés aux personnes pouvant les corriger par l’intermédiaire de solutions web de Bug Tracking tels que Mantis ou encore Jira. Les testeurs ne font pas que noter les soucis qu’ils remarquent, ils décrivent surtout le plus précisément possible la manière de les reproduire. Une fois le bug assigné à un département (ou directement à un employé), les personnes du QA s’assurent de sa correction en fonction du jalon d’avancement. Lorsqu’un éditeur (ou un constructeur) finance un studio pour produire un titre, il octroie généralement entre l’alpha et la bêta une partie de ses ressources au bug tracking afin de soulager le QA interne du développeur. Pour les départements liés à la production, cela sous-entend qu’ils vont recevoir deux fois plus de bugs qu’à l’accoutumée, dans les derniers mois du projet. “Tous les studios de développement d’une certaine taille ont des ressources dédiées à l’assurance qualité, au moins pour s’assurer que ce qu’ils envoient à leur éditeur n’est pas trop cassé” nous informe Jérôme Vu Than. Il continue : “les éditeurs ont également la possibilité de faire appel à des sociétés spécialisées dans le test, telles que Babel Media ou Enzyme”.

Mantis et Jira, deux solutions très utilisées pour le tracking de bug.

Les playtests face aux soucis de game design

Contrairement aux testeurs QA, les playtesteurs ne traquent pas les problèmes techniques liés à une version, mais plutôt ses soucis de design. Les playtests s’appuient en effet sur un panel de joueurs invités dans des sortes de laboratoires afin que des observateurs comprennent de façon pragmatique ce qui fonctionne et ce qui ne fonctionne pas en termes de mécaniques. Les failles d’accessibilité et de challenge sont particulièrement observées, de même que tout ce qui est lié à la compréhension (ou non) des règles. Les checkpoints mal placés, les règles énervantes, les ennemis trop nombreux, les niveaux labyrinthiques sont autant d’éléments surveillés lors de ces tests. La méthodologie utilisée par les grands éditeurs est simple. Les équipes reçoivent des versions de softs encore en développement à partir desquelles elles établissent un guide. Ce guide détermine ce qui doit normalement être compris rapidement (les basics), et ce qui doit normalement être assimilé après plusieurs parties (l’advanced). Grâce aux observations et aux questions posées aux joueurs sur ce qu’ils comprennent (de l’interface, des règles, etc.), des données sont établies pour pointer objectivement, voire scientifiquement, ce qui ne fonctionne pas dans la version playtestée.

Ces données servent à l’élaboration de rapports qui sont envoyés aux studios de développement afin qu’ils prennent connaissance des observations. Pour chaque élément relevé durant les tests, des conclusions sont établies. Des tableaux sont rédigés contenant des données sur l’observation, le problème que cela occasionne sur l’envie de progresser, et enfin les façons de corriger le souci, qui prennent la forme de suggestions pouvant être suivies par les développeurs. Si ces playtests s’appuie la plupart du temps sur des données objectives basées sur des observations et des relevés, ils laissent également une place au subjectif. À des moments précis du développement, les joueurs sondés sont invités à donner des notes aux niveaux testés afin d'aider les concepteurs à comprendre ce qui doit être retravaillé. Des scènes entières peuvent être coupées suite à ces résultats.

Les playtests sont organisés pour repérer les problèmes liés au game design d'un titre.

Les indéboulonnables “TRC”, remparts brandis par les constructeurs

La soumission TRC, pour “Technical Requirements Checklist”, est une étape obligatoire dans la publication d’un jeu sur une plateforme. Durant une bonne semaine, le jeu passe une série de tests chez le constructeur. Lorsqu’un constructeur tel que Microsoft ou Sony finance un titre, il en effectue lors de l’alpha et la bêta. Cette certification n’est pas mise en place pour traquer des bugs qui gâcheraient l’expérience de jeu. Elle doit surtout faire ressortir d’éventuels soucis strictement techniques liés à la stabilité du produit lors d’événements particuliers comme la gestion des profils, ou une pause prolongée. Elle veille également à ce que les Succès/Trophées se débloquent bien, ou encore à ce que les textes s’affichent convenablement dans les différentes langues sélectionnables. Par le passé, Jonathan Blow (Braid , The Witness ) a vivement critiqué ces TRC qu’il juge aberrants. En 2012, il déclare en effet que le système de certification du Xbox Live Arcade rend les jeux “plus mauvais que meilleurs”. Est pointé du doigt, entre autres, le message qui doit obligatoirement spécifier que lorsque le jeu sauvegarde, il ne faut pas éteindre la console. “C'est parce que vous risquez de corrompre le jeu sauvegardé. Eh bien, devinez quoi... la solution à ce problème est de mettre en place un système de sauvegarde plus robuste (...) du côté du constructeur” assène Blow.

The Witness est sorti le 26 janvier 2016. Jonathan Blow l'a développé pendant 7 ans.

C’est surtout lors de la livraison du master que le soft subit les tests les plus poussés. “Une équipe spécifique chez l’éditeur, complètement isolée, passe toute une série de vérifications selon un cahier des charges” nous confie l’ancien Project Manager de Quantic Dream. Il ajoute : “à peu près une semaine plus tard, un rapport est envoyé. Si le nombre de points est en dessous d’un certain total, la soumission passe et le jeu devient gold”. En cas de certification rejetée, le studio doit retravailler sa proposition. Le problème, c’est que sur un jeu en qualité master, la moindre correction peut casser un script et entraîner l’arrivée de nouveaux bugs. “Les studios disposent d’un cahier expliquant les causes détaillées de l’échec de la certification. Chaque changement est méticuleusement suivi” affirme Jérôme. Rater une soumission peut entraîner un report, les constructeurs n'exécutant pas de tests TRC quotidiennement. Afin de s’éviter de mauvaises surprises, les équipes de développement envoient des version avant la date officielle de la certification TRC dans le but de mieux préparer le terrain. Ce “TRC à blanc” permet d’avoir un premier état des lieux avant la soumission définitive, sans conséquence fâcheuse pour qui que ce soit. Sauf peut-être pour le développeur peu méticuleux. “Si tu vises vingt-cinq points et que t’en as en fait deux-cent-cinquant-mille, tu peux commencer à t’inquiéter” s’amuse Jérôme.

“Tu me certifies que ce patch corrige le problème ?”

Avec la démocratisation d’Internet à la fin des années 1990, les patchs se sont multipliés tels les croassements d’amphibiens au printemps. D’abord sur PC puis sur les consoles de jeux, où les espaces de stockage et les ports éthernet ont créé un terreau fertile à ces correctifs. Pour rappel, Unreal Championship et Mechassault furent patchés dès 2003 sur la première Xbox, avant que la pratique se démocratise à d’autres consoles. Le désormais célèbre patch day one est mis en place pour fixer les bugs potentiellement importants, voire graves, qui n’ont pas été vus lors des tests. Ces correctifs suivent les mêmes certifications : ils sont envoyés à l’éditeur/constructeur qui les applique au jeu, il les teste, puis il les valide quand tout lui semble bon. Jusqu’au mois de juillet 2013, les certifications des mises à jour étaient à la charge des studios indépendants, sur Xbox. Les petits développeurs ont régulièrement critiqué ce procédé, à l’instar de Phil Fish, célèbre créateur d’un FEZ corrompant les sauvegardes. Le titre resta pendant une bonne année dans cet état à cause du prix de la certification du patch “s’élevant à plusieurs dizaines de milliers de dollars”.

Aujourd'hui, les patchs de nos jeux sont courants, même sur consoles.

Malgré les tests internes et les certifications, nous continuons de voir arriver des jeux cassés au moment de leur sortie. Certains éditeurs repoussent jusqu’au dernier moment les accords de non-divulgation (NDA), quand ils envoient encore une copie à la presse. D’autres publient toujours plus de patchs afin de corriger les gros problèmes émanant de leur création. À l’époque des réseaux sociaux et de Reddit, les grands du jeu vidéo sont pourtant au courant de la mauvaise publicité qu’engendre un titre mal terminé. “Toute la chaîne de production vise l'excellence, mais c’est parfois difficile à respecter après des années écoulées de conception” conclut Jérôme, l'ancien Senior Producer de Gameloft.