Dans le précédent épisode de cette chronique consacrée au playtests, j’ai exposé les raisons pour lesquelles ces derniers sont appelés à jouer un rôle grandissant dans le développement des jeux. Dans une industrie ou les jeux représentent un risque financier croissant pour les éditeurs, les playtests sont l’assurance-qualité du gameplay. Aujourd’hui, je vais partager avec vous mon expérience sur la façon de préparer et de conduire ces playtests.

A L’ECOUTE DES CLIENTS : LES EQUIPES DE DESIGN

La chose fondamentale dont il faut être conscient est que le rôle des playtests n’est pas de sanctionner les équipes de design (game ou level design) mais de les aider. Cette remarque est fondamentale car elle conditionne toute mon approche des playtests :

D’abord, il faut respecter le travail accompli par les équipes de design. Ayant moi-même des responsabilités en game et en level design, je sais à quel point il est difficile de faire « un bon jeu ». Il faut avoir du respect pour ceux qui donnent tout leur cœur afin d’offrir le meilleur jeu possible et ne pas mépriser leur travail.

Ensuite, les playtests se doivent d’être à l’écoute des besoins exprimés par les équipes de design. Un bon réglage de map ou d’un mécanisme de jeu est souvent le résultat d’essais et d’erreurs. Les designers le savent et sont demandeurs d’expérimentation ; Les playtests peuvent leur donner l’opportunité de tester leurs hypothèses. Les playtests doivent donc s’adapter à leurs demandes.

Enfin, les résultats des playtests doivent être mis à la disposition des intéressés le plus rapidement possible car le développement d’un jeu est souvent à court de temps.

LA PREPARATION D’UNE CAMPAGNE DE PLAYTEST

Une campagne de playtest demande environ un mois de préparation. Il vous faut d’abord en définir ses objectifs car ce sont eux qui déterminent quel type de playtesteurs il faudra recruter, l’ampleur des sessions (2, 4, 8, 12 joueurs) et leur durée (d’une demi-journée à une semaine). La logistique doit être mise en place et il faut préparer le cadre juridique (NDA, éventuel mécanisme de rémunération des playtesteurs lorsque ces derniers sont appelés à participer à des sessions dépassant une demi-journée). Il faut enfin préparer les équipes de design à tirer le meilleur parti des playtests.

On ne cultive pas de beaux fruits dans une terre aride. Le terreau des playtests se sont les playtesteurs eux-mêmes. Le choix de ces derniers représente une bonne moitié du succès d’une campagne de playtest. Il faut donc y consacrer du temps, de l’énergie, parfois un peu d’argent et de la patience. Le recrutement prend du temps car il faut recruter un maximum de candidats, de façon à avoir un « réservoir » de playtesteurs et il faut les évaluer. L’objet de l’évaluation est bien entendu de juger de la compétence ludique du candidat mais aussi de son sens de l’analyse et de sa capacité à s’exprimer.

L’évaluation peut prendre plusieurs formes. Une première sélection peut s’effectuer par le biais d’un questionnaire plus ou moins complet que le candidat doit remplir. Mais la vraie évaluation doit se faire lors de sessions au cours desquelles on peut voir les candidats jouer. Un protocole doit être établi de façon à obtenir des résultats aussi homogènes que possible. Il n’y a pas de protocole d’évaluation « à tout faire » et il faut s’adapter aux circonstances. Lorsque j’ai monté la structure de playtest du studio Ubisoft de Bucarest j’ai été confronté à un problème particulier. Nous avions besoin de playtests pour des jeux sur consoles alors que tous les joueurs rencontrés sur place ne connaissent que le PC. Il m’a fallu mettre en place un protocole particulier pour évaluer avec quelle aisance nos candidats Roumains pouvaient s’adapter au jeu sur console. Le protocole consistait à leur expliquer brièvement les contrôles et le gameplay d’un jeu complexe (le mode multi-joueurs de Splinter Cell – Chaos Theory), à les « lâcher » dans le jeu et à observer avec quelle vitesse ils s’adaptaient au gameplay. Cette méthode de sélection s’est montrée très efficace.

La sélection des candidats va donc se faire en fonction des objectifs de la campagne de playtest. On peut n’avoir besoin que de très bons joueurs maîtrisant déjà le genre, ou au contraire de novices si on veut « playtester » l’accessibilité du jeu.

La communication autours des playtests prend également du temps. Pour que les candidats se pressent à votre porte, il faut qu’ils en soient avertis. D’après mon expérience le recrutement par le biais d’annonces postés sur des sites généralistes permet d’obtenir un grand nombre de candidats mais beaucoup sont trop jeunes (attention à la législation du travail !) et leur profil est plutôt celui de joueurs occasionnels. Une bonne façon de recruter des joueurs expérimentés est de passer par les forums, les clans de joueurs ou les magasins spécialisés.

L’ORGANISATION DES SESSIONS

J’aborderai trois aspects : la composition de l’équipe, la préparation du protocole de playtest et la logistique.

• Le recrutement doit être lancé 4-5 jours avant la session concernée. A ce stade, le responsable des playtests dispose dans sa base de données d’un certain nombre de candidats qu’il a déjà évalué. Il peut donc choisir ses playtesteurs en fonction du thème de la futur session Les invitations se font par mail. C’est à ce stade que l’on comprend l’intérêt d’avoir un grand nombre de candidats car beaucoup ne sont pas disponibles en permanence. Il faut donc se préparer à faire des mailings massifs pour avoir la garantie de disposer de suffisamment de playtesteurs le jour venu. Il vaut mieux aussi inviter un playtesteur de plus nécessaire car les désistements de dernière minute sont monnaie courante. Il est aussi souhaitable de demander aux playtesteurs de confirmer par mail leur venue.
   
• La mise au point du protocole est une partie importante de la préparation d’une session. Certains playtests sont organisés en fin de développement pour affiner les réglages d’une map ou d’un système de jeu. Le protocole pour ce genre de playtest est souvent simple et générique. Il faut faire jouer les playtesteurs un maximum de temps, noter les statistiques de jeu et organiser des sessions de questions ouvertes.
  
  Mais le moment ou les playtests sont souvent le plus utiles est au cours du développement, alors que le système de jeu et les maps sont en cours de gestation. N’oublions pas que plus on détecte des problèmes tôt dans le cycle de développement, plus il est facile de les corriger … à moindre cout. Lors du développement des maps de la version multi-joueurs de Splinter Cell – Chaos Theory, j’avais organisé des playtests pour évaluer la structure des maps. Ces dernières étaient alors à un stade embryonnaire. Nous nous sommes vite rendu compte, y compris le level designer qui l’avait conçu et qui avait assisté à la session, que la map était trop grande. Ayant constaté par lui-même le problème, il a immédiatement refondu sa map ce qui ne lui a pas pris beaucoup de temps puisque la map n’était qu’un prototype. Au final, Aquarius est devenu une des maps es plus populaires du jeu.
  
  Les playtests permettent justement de mettre en lumière de nombreux problèmes et permettent de valider les hypothèses de l’équipe de design. Lors du développement de la version multi-joueurs de Splinter Cell – Pandora Tomorrow, des playtests spécifiques ont été conduit pour régler les caractéristiques de certains équipements comme la grenade fumigène. Cette dernière est un des accessoires les plus utilisés des espions car son nuage ralenti le déplacement de ses adversaires, les mercenaires, et elle peut les endormir si ces derniers y restent trop longtemps. Régler les paramètres de la grenade fumigène n’a pas été simple. Si la zone d’effet était trop grande, elle constituait une arme imparable pour les attaquants (il leur suffisait de faire exploser une grenade dans un couloir pour en interdire l’accès à leurs adversaires). A l’inverse, une zone d’effet trop petite aurait rendu la grenade complètement inutile (les défenseurs disposent de modes de vision leur permettant de voir partiellement au travers du nuage). D’autres sessions ont été conduite avec des joueurs débutants pour évaluer comment ils arrivaient à naviguer dans des maps qu’ils ne connaissaient pas.
  
  Pour être efficace, les protocoles doivent donc s’adapter aux problèmes constatés lors de précédentes sessions et aux demandes de test de l’équipe de design. Cette proximité avec les besoins de l’équipe de développement est une des clés du succès des playtests. Je reviendrai plus loin sur ce point.
   
• Enfin, la logistique. De bons playtests demandent une version stable et peu buggée du jeu. Lorsque les playtests se déroulent en cours de développement, c’est souvent difficile. Il est pourtant impératif que le jeu soit suffisamment stable et que les maps aient été débarrassées des bugs les plus pénalisant comme l’impossibilité de grimper à une échelle. Un protocole de livraison du jeu doit être mis en place avec l’équipe de développement. Cette dernière doit remettre la version du jeu pour les playtests à l’équipe interne de debug qui fera une rapide « passe » sur le jeu afin de s’assurer que la version est playtestable. En cas de problème, la proximité entre les équipes de debug et de développement permet de corriger rapidement les problèmes et de disposer d’une version stable pour les playtests. Une telle organisation demande beaucoup de discipline de la part de toute l’équipe. Il est également souhaitable de préparer à l’intention des level designers et des infographistes une check-list leur permettant de s’assurer par eux-mêmes que leurs maps sont exempts de bug pénalisant pour le gameplay. Enfin, le responsable de la session de playtest doit s’assurer par lui-même que la version est effectivement playtestable.

LE DEROULEMENT DES SESSIONS

Les playtests sont particulièrement instructifs lorsque les membres de l’équipe de design assistent aux sessions de playtest les concernant. En effet, un game ou un level designer base son travail sur des hypothèses qu’il ou elle va émettre concernant le comportement des joueurs. Or ces derniers ne réagissent pas toujours comme prévus et il faut tenir compte de leur pluralité. En voyant par ses propres yeux la façon dont de vrais joueurs utilisent un équipement ou une topologie de map, et en leur demandant à la fin de la session les raisons de leur comportement, le designer peut très rapidement corriger le tir. Une démonstration sera toujours plus efficace qu’un long discours ! Il est donc vivement conseillé de demander aux designers d’assister aux playtests et donc, de conduire ces derniers au sein même du studio de développement. Les playtests déportés sont valables pour les réglages de map ou de système de jeu mais sont moins adaptés à des playtests portant sur un jeu en cours de gestation. Bien entendu, les visiteurs doivent se tenir à un certains nombre de règles. Ils ne doivent pas émettre de commentaires ou poser leurs questions tant que le responsable de la session ne les y a pas autorisés afin de ne pas influencer le jeu ou le jugement des playtesteurs.

S’il est souhaitable que les designers assistent aux playtests, il est impératif que le responsable en fasse de même. Ce dernier ne doit pas se contenter d’organiser la session et de poser ses questions en fin de session. Il doit regarder les playtesteurs jouer. La raison en est la suivante. Les playtests conduit en début de développement se déroulent souvent avec un nombre limité de playtesteurs. Les problèmes soulevés sont très nombreux et la version du jeu change fréquemment. Les commentaires recueillis sont donc peu nombreux, hétérogènes et parfois contradictoires. Le responsable doit faire la part des choses. Il doit faire sa propre évaluation de la pertinence des commentaires. Cette implication du responsable des playtests peut être contestée. Dans certains cas, un responsable des playtest doit se comporter comme un simple observateur. C’est en effet la meilleure attitude à adopter lors des playtests de fin de développement, lorsqu’il faut effectuer les réglages fins du système de jeu. L’objet est alors de recueillir un maximum de données statistiques accumulées avec un grand nombre de playtesteurs. Mais lors des playtests en début de développement, lorsqu’il faut évaluer les forces et faiblesses d’un système de jeu ou de maps embryonnaires, la faible quantité des données recueillies et leur hétérogénéité militent en faveur d’un comportement plus offensif, plus réactif, plus impliqué. Le responsable des playtests doit alors « mouiller sa chemise », tirer des conclusions à partir de données incomplètes. Il y a risque d’erreur mais mon expérience m’a montré que les résultats des playtests sont alors plus concrets et donc plus facilement utilisables.

C’est ce que mon expérience au sein d’un des meilleurs studios de développement de France m’a appris. Le responsable des playtests doit s’impliquer réellement dans la qualité finale du jeu et non pas se contenter d’en être un simple observateur. Cette conclusion milite à nouveau en faveur de la proximité de la structure de playtest par rapport au studio de développement, du moins pour les playtests les plus précoces.

LE DEBRIEFING

Nous en arrivons au résultat final d’une session de playtest. L’idée générale est d’apporter aussi rapidement que possible les conclusions du playtest à ceux qui en ont le plus besoin, les designers et les responsables du projet. Le débriefing peut prendre plusieurs formes.

D’abord, à chaud, les membres de l’équipe de design qui ont assisté aux playtests peuvent questionner directement les playtesteurs. Ils sortent le plus souvent de la salle de playtest avec quelques idées fortes en tête.

Ensuite, vient le compte-rendu. Ce dernier doit bien distinguer entre les faits (statistiques, opinions des playtesteurs) et les synthèses émis par le responsable. Il est important de fournir les informations brutes de façon à ce que les designers sachent sur quelles bases le responsable a construit ses synthèses. Ce dernier peut se tromper et doit être prêt à l’admettre. Mettre toutes les cartes sur la table est un bon moyen d’établir un rapport de confiance avec ceux qui vont lire le compte-rendu. N’oublions pas que l’objet des playtests est d’améliorer le jeu, pas de régler des comptes comme je l’ai vu faire.

Enfin, j’avais commencé à expérimenter avec le studio Ubisoft de Milan un protocole permettant à un studio déporté (dans une autre ville ou même un autre pays) d’obtenir un compte-rendu à chaud sur un playtest de map. Nommé D3 (Debrief Dynamique à Distance), ce protocole consiste à établir rapidement une liste des principaux problèmes constatés, de créer une session en ligne ou les designers concernés (au studio de développement) et le responsable de la session de playtest (au studio de playtest) se retrouvent. Ils peuvent alors se promener dans les maps et l’équipe de playtest peut expliquer avec beaucoup de précision la teneur des problèmes et les éventuelles solutions. Un playtesteur peut même se joindre à eux et dialoguer. Le jeu doit évidement supporter des sessions en ligne ainsi que la communication orale. Ce protocole fonctionne bien mais demande une logistique complexe.

Donnez votre avis sur le forum de l'afjv