Niveau 12 – Le test en solo

L’article original « Level 12: Solo Testing » a été écrit par Ian Schreiber et fait partie d’un cours de game design en ligne, publié sur le blog Game Design Concepts.

L’article original et cette traduction sont publiés sous licence Creative Commons (Attribution).

N’hésitez pas à visiter le blog de Ian Schreiber et suivre son compte Twitter.

~ ~ ~ ~ ~ ~ ~

À ce stade vous avez quelques idées, et vous avez un peu de feedback. Comme beaucoup de choses dans la vie et dans le game design, vous pourriez vous asseoir ici éternellement pour évaluer quels sont les meilleurs choix… mais à un certain point vous aurez besoin de travailler en direction de votre but. Choisissez une direction et allez-y, même si cela ne pourrait pas être la meilleure. Ayez confiance dans le fait que vous serez capable d’utiliser le processus itératif pour corriger les erreurs que vous faites le long du chemin.

Aujourd’hui j’aimerai couvrir le concept général de playtesting. Comme nous le verrons, il y a différents types de playtesting, et il est important d’être capable de faire la différence entre eux de manière à retirer un maximum de valeur du temps passé.

Lectures

Il n’y a pas de lectures pour aujourd’hui, autre que ce post de blog. Prenez le temps que vous auriez passé à lire et utilisez-le pour travailler sur votre Projet de Design.

Différents types de playtesting

Le mot « playtesting », comme le mot « jeu », est sur-utilisé et peut signifier différentes choses pour différentes personnes. En général, le terme couvre n’importe quelle activité où vous jouez à un jeu en cours de création dans le but de l’améliorer. Mais différents playtests peuvent avoir différents buts, et il est important de savoir quels sont vos buts avant que vous fassiez quoi que ce soit.

Je serai un peu lâche sur la terminologie ici, alors dans ce cas les concepts sont plus importants que les étiquettes que je leur donne.

Bug Testing1 (ou Assurance Qualité)

Le propos de l’Assurance Qualité est de trouver des erreurs dans le comportement du jeu en relation à son design. Le « fun » n’entre pas dans l’équation. Si le designer dit que le jeu devrait faire une chose et en fait réellement une autre (même si ce que le jeu fait peut être meilleur), c’est un bug qui doit être identifié.

Normalement, nous pensons au bug testing comme étant spécifique aux jeux vidéo. Les jeux de plateau ont un type de test correspondant, ou le propos est de trouver des trous dans les règles et des impasses dans le gameplay – des vides dans le jeu que le designer n’a pas couvert.

Focus Testing2

Dans un focus test, vous regroupez les joueurs qui font partie du public cible de manière à déterminer à quel point un jeu sert leurs besoins. C’est d’habitude réalisé pour des raisons marketing, mais si des game designers sont impliqués cela peut aussi aider à rendre le jeu plus agréable pour ce public particulier.

Usability Testing3

Dans un test utilisateur, on donne aux joueurs des tâches spécifiques à accomplir de manière à voir s’ils comprennent comment contrôler le jeu. C’est fait couramment dans l’industrie logicielle pour faire en sorte qu’un morceau du logiciel soit facile à apprendre et facile à utiliser. Les jeux vidéo peuvent aussi tirer partie de cela, et les résultats des tests utilisateur peuvent être exploités soit pour changer les contrôles ou soit modifier les niveaux afin d’enseigner ces contrôles plus efficacement.

Dans les jeux de plateau, l’utilisabilité est sans aucun doute importante, parce qu’il n’y a pas d’ordinateur pour répondre aux entrées du joueur. Si vous ne comprenez pas comment les maisons fonctionnent dans le Monopoly et les placez sur les cases Caisse de Communauté, le jeu ne vous en empêchera pas. En observant les joueur qui essayent de jouer à votre jeu, vous pouvez beaucoup apprendre sur comment concevoir les différents éléments du jeu de manière à ce qu’ils soient faciles et intuitifs à utiliser.

Balance Testing4

Un jeu fun peut rapidement devenir ennuyeux s’il existe un exploit qui permettrait à un joueur d’outrepasser la plupart des choix intéressants dans le jeu. Si une seule stratégie permet de gagner et c’est juste une question de quel joueur suit le mieux cette stratégie, alors ce n’est pas aussi intéressant que s’il y a plusieurs chemins de victoire. De la même manière, si un joueur a un avantage clair sur les autres, il est importe d’identifier cela de manière à ce que les joueurs ne sentent pas que le jeu est unfair. Le propos de ce type de test est d’identifier les déséquilibres dans le jeu de manière à ce que le designer puissent les corriger.

Fun Testing

Un jeu peut être utilisable, équilibré et fonctionnel et pourtant rester inintéressant. Ce « fun factor » évasif peut être difficile à concevoir de façon intentionnelle, mais quand les gens jouent au jeu il est clair s’ils s’amusent ou pas. Certains aspects du jeu peuvent être plus fun que d’autres, alors il est aussi important de comprendre quelles parties du jeu ont besoin de rester identiques…et pas uniquement quoi changer.

Toutes ces formes de test ont certains éléments en commun. Les meilleurs pratiques sont similaires sinon identiques. Toutes sont importantes pour le succès d’un projet. Alors pourquoi faire une distinction ?

La raison est que chacun est approprié à différentes étapes de finition dans un projet. Chaque type de test a différents buts, et vous devez savoir quel est votre but avant de pouvoir l’atteindre.

Ordre des effets

Quand devriez vous réaliser un type particulier de playtest ? Dans quel ordre les faites-vous ? Beaucoup dépendent des spécificités de votre projet, alors une partie de cela sera lié à votre jugement en tant que designer. Toutefois, voici quelques principes de base.

  • Très tôt dans ce projet, vous avez besoin de faire en sorte que votre projet atteigne ses buts de design (habituellement le « but de design » est de faire un jeu est soit fun à jouer). Tester pour le fun est nécessaire pour faire en sorte que vous ne passiez pas trop de temps à construire sur les mauvaises fondations. Si vous faites un jeu pour un marché spécifique, le test de focus peut être souhaitable à un stade précoce aussi, simplement pour demander au public cible si un jeu avec un concept particulier leur paraît intéressant.
  • Une fois que vous avez quelque chose, vous avez besoin de solidifier les mécaniques. Concevez le jeu en entier, en faisant en sorte de vous occuper de tous les détails. Testez pour les « bugs ». (Notez que le bug testing dans les projets logiciels est souvent fait de façon continuelle tout le long du projet, et augmente en intensité vers la fin. Les jeux non numériques sont plus faciles à « débugger » pourtant, et un « bug » peut arrêter un playtest en plein déroulement, alors il est important pour nous d’avoir un ensemble complet de règles très tôt dans le processus.).
  • Une fois que le jeu est fun et le design est complet, passez graduellement du test pour le fun au test pour l’équilibre du jeu. Faites en sorte que toutes les valeurs numériques et les capacités du joueur soient là où vous voulez qu’elles soient.
  • Vers le fin, quand un jeu fonctionne et est équilibré, vous voudrez plus réfléchir sur l’utilisabilité du jeu. Quand vous changez l’utilisabilité vous ne changez pas de mécaniques, mais plutôt la façon dont ces mécaniques sont présentées visuellement aux joueurs. C’est une étape importante souvent négligée. Si vous avez déjà rencontré un jeu que vous ne pouviez apprendre que s’il vous était expliqué par un autre joueur (par opposition à lire les règles par vous-même), c’est le type d’échec d’utilisabilité que vous voulez éviter dans vos propres projets. Vous pouvez aussi faire des focus test supplémentaires à ce moment, pour faire en sorte que le thème et les éléments visuels du jeu soient attrayant pour le public cible.

Comme je l’ai dit, ce sont juste de lignes directrices. Il est incroyablement important que votre jeu soit bien reçu par un public particulier ; par exemple, vous pourriez faire un focus test tout le long du projet à toutes les étapes. Ne laissez pas cet ordre des choses être votre maître.

Différents types de playtesteurs

Comme il existe plusieurs type de tests, il y a aussi différents types de testeurs. Chaque type de testeurs possède ses propres forces et faiblesses, et certains sont plus importants pour certains types de test que d’autres.

  • Vous-même. Vous êtes votre playtesteur le plus précieux. N’oubliez pas votre capacité à jouer à votre propre jeu par vous-même. Vous connaissez votre jeu mieux que quiconque.
  • D’autres game designers. Si vous êtes assez chanceux pour connaître personnellement d’autres game designers compétents, vous pouvez faire des tests très utiles avec eux. Ils sont capables d’analyser de façon critique votre jeu et proposer des solutions de designer. (Si vous ne connaissez pas de designers professionnels, peut-être que vous pouvez au moins prendre contact avec les autres participants de ce cours.)
  • Les amis proches, la famille et les confidents. Les gens qui sont proches de vous et qui sont d’accord pour donner de leur temps pour tester votre jeu sont précieux. Ils sont accessibles et peuvent se rendre disponibles pour vous faire une faveur. Prenez soin d’eux, et n’abusez pas de leur gentillesse. Notez que ces personnes peuvent ne tomber dans aucune des autres catégories, alors pendant que vous êtes bons aux premiers tests, ils ne pourrait pas être appropriés dans des tests plus focus pour les bugs ou l’équilibrage comment ils ne savent pas ce qu’il faut chercher.
  • Les joueurs expérimentés. Les joueurs compétents sont bons pour trouver des « exploits » et des stratégies dominantes dans un jeu, et sont appropriés pour le test d’équilibrage.
  • Parfaits inconnus. Les gens dans votre public cible sont appropriés pour les test de focus et d’utilisabilité, et ils sont absolument critiques quand tester pour le fun. Les trouver peut-être délicat, cependant, parce que ce n’est pas de notre nature de simplement marcher vers quelqu’un que nous n’avons jamais rencontré et leur demander de jouer à un jeu. Nous parlerons plus en détail de tout cela dans les semaines à venir.

Ordre de familiarité

En général, vous voulez voyager parmi les testeurs dans l’ordre du plus familier au moins familier. Testez par vous-même d’abord, puis avec vos amis proches, puis avec les amis qui sont utiles (parce que ce sont des designers, des joueurs, ou font partie du public cible), et ensuite avec des étrangers.

Si vous montrez votre travail à d’autres personnes trop tôt, il sera certainement dans un tel état brut avec de nombreux problèmes de design et trous dans les règles que cela fera fera perdre leur temps et les frustrera et vous voulez traiter vos playtesteurs mieux que cela. Aussi, si vous commencez à playtester avec des étrangers trop tôt dans votre processus, vous pouvez ne pas obtenir de feedback positif – si votre prototype de jeu est dans un état brut avec seulement les composants et des visuels de base, par exemple, les playtesteurs pourraient être si occupés à commenter la pauvre qualité des pièces qu’ils ne seront pas capable de se concentrer sur le gameplay.

À ce stade vous pourriez être tenté de simplement faire tout le playtesting par vous-même, de façon à ce que vous n’ayez pas besoin de vous reposer sur d’autres personnes d’en garder la trace. En pratique, le designer devient au bout d’un moment trop proche de son propre projet et est si familier avec les systèmes du jeu qu’il peut manquer certains défauts évidents. Si vous garder le même ensemble de playtesteurs trop longtemps, il souffriront aussi de ce problème. Vous aurez besoin d’amener un ensemble de regards neufs pour étudier votre jeu sur une base continue à travers tout le projet.

Jouer par vous-même

Dans les premières parties du playtesting, quand vous jouez au jeu par vous-même, voici certaines choses que vous devriez regarder :

Est-ce que le jeu atteint ses objectifs de design ?

Est-ce fun, ou au moins pour vous ? Bien que vous ne soyez pas le playtesteur idéal pour juger de l’efficacité la plupart du temps, si vous ne vous amusez pas, alors la plupart des gens ne s’amuseront pas non-plus.

Est-ce qu’il y a des trous dans les règles ?

Un « trou » est une situation où les règles simplement ne disent pas comment procéder. Par exemple, peut-être qu’une de vos règles est que l’armée d’un joueur peut attaquer l’armée d’un autre joueur, mais vous n’avez pas encore de règles pour résoudre l’attaque. Que se passe t’il dans ce cas ? En pratique, ce qui est arrive est que les joueurs restent assis et attendent pendant que le designer détermine ce qu’il faut faire !

En exemple, prenez en considération les règles pour le Morpion joué sur une grille 4×4 :

  • Joueurs : 2
  • But du jeu : Alignez les symboles en ligne droite
  • Mise en place : Dessinez une grille carrée de 4×4
  • Déroulement de la partie : À votre tour, placez votre symbole (« X » ou « O ») sur une case vide.
  • Résolution : Si n’importe quel joueur à sont tour a une série de 4 de ses symboles en ligne droite (orthogonalement ou diagonalement), il gagne.

Si vous essayez de jouer à ce jeu simplement en suivant les règles, vous réaliserez rapidement que vous ne pouvez même pas démarrer – il n’est dit nul par quel joueur est X ou O, ou qui joue en premier ! Pour corriger cela, vous devriez ajouter une situation pour gérer cela. Par exemple :

Mise en place : Dessinez une grille carrée de 4×4. Choisissez un premier joueur, qui reçoit le symbole « X ». l’autre joueur reçoit le symbole « O ».

Il y a-t-il des impasses ?

Une « impasse » est un état du jeu où il n’y a aucun moyen d’avancer, mais le jeu n’est pas résolu. Prenez en considération notre version révisée du Morpion 4×4 ci-dessus. Supposons que les deux joueurs remplissent toutes les cases sur le plateau sans que personne ne gagne. À ce stade le jeu ne peut pas avancer, parce que les règles disent qu’un joueur doit placer son symbole sur une case vide. Il n’y a pas de case vide, alors le joueur ne peut jouer à son tour. Mais il n’y pas aussi de résolution, parce que aucun des joueurs n’a gagné. Dans ce cas, une nouvelle règle devrait être ajoutée (comme : en fin de partie, si aucun des joueurs ne peut jouer à son tour, et aucun n’a gagné, alors le jeu se termine en partie nulle).

Est-ce qu’il y a des règles pas claires ?

Il est naturel pour nous d’assumer des choses qui sont dans notre tête, jusqu’au point où nous oublions souvent de les écrire dans nos règles. Essayez de regarder vos règles et voir s’il y a quoi que ce soit que vous assumiez que vos joueurs ne voient pas.

Est-ce qu’il y a des « exploits » évidents des règles ?

Est-ce qu’une il y a une stratégie unique qui permet de gagner le jeu facilement ? Essayez de la trouver. C’est beaucoup moins embarrassant si vous la trouvez et la corrigez vous-même, par opposition au fait qu’elle soit découverte pas vos playtesteurs (ou pire, vos joueurs après que vous ayez publié le jeu). La clarté et les exploits sont souvent difficiles à trouver dans votre propre jeu ; vous avez essayé de concevoir ce jeu pour qu’il n’ait pas de problèmes après tout. Pourtant, faites un effort honnête, et parfois vous serez récompensés en trouvant et en corrigeant des erreurs très tôt (ce qui vous sauvera beaucoup de temps sur la durée, en vous laissant plus de temps pour itérer sur d’autres parties de votre design).

Vous pourriez penser que chercher les exploits est quelque chose à faire plus tard dans le projet lorsque vous équilibrez le jeu. Parfois c’est le cas. C’est une question de degrés. Si un exploit est si puissant et si évident qu’il empêche vos playtesteurs de vous donner l’information réelle sur votre jeu, corrigez-le maintenant.

Difficultés du test en solo

Il y a plusieurs choses qui sont difficiles à tester seul :

  • Les jeux en temps réel à plusieurs joueurs, comme les jeux où vous devez taper sur une carte ou dire une réponse plus rapidement que votre adversaire.
  • Les jeux à information cachée, ou chaque joueur a une information que lui seul connaît et qui est importante de garder secrete envers les adversaires.
  • Les jeux d’échange, de négociation et d’enchère, où chaque joueur doit placer une valeur sur un objet, et différents joueurs pourraient évaluer les choses différemment (en particulier quand les joueurs peuvent artificiellement retirer des hauts prix ou monter les coûts d’un objet lors d’une enchère simplement pour faire payer plus leurs adversaires.)

Pour les deux derniers, il est possible de jouer de toute façon, en limitant simplement vos actions à ce que vous pensez que vous feriez si vous étiez dans la situation de chaque joueur, en sachant uniquement ce qu’ils devraient raisonnablement savoir. Certaines personnes trouvent cela plus difficile que les autres.

La réponse la plus simple ici est, pour le propos de ce projet, de ne pas utiliser de mécaniques que vous ne puissiez pas tester vous même. L’alternative est d’amener un autre joueur ou deux dans ce cas seulement, après que vous ayez amené les choses aussi loin que vous le pouviez par vous-même.

Laissez-le mûrir

Les designers expérimentés parlent souvent d’un jeu « qui se fait lui-même » – comme si le jeu avait une vie propre, et le designer se contente de le guider plutôt que le créer. En surface, cela semble étrange parce qu’en réalité, le jeu est juste posé ici et ne fait rien à moins que le designer y joue ou le change. Que se passe t’il donc ?

Je pense que ce qui se passe réellement est que la création d’un jeu est un processus d’apprentissage. Vous pouvez avoir une idée de là où vous voulez que votre jeu arrive, mais la version finale peut être très différente de ce que vous aviez imaginé à l’origine. La raison pour laquelle il change est qu’au début, vous ne savez pas grand-chose de votre jeu. Vous avez des idées de base, mais vous ne savez pas réellement comment les mécaniques vont interagir, ou quelles dynamiques et esthétiques réelles seront. Au fur et à mesure où vous playtestez, vous apprenez plus sur comment les systèmes de votre jeu fonctionnent. Au fur et à mesure où vous apprenez, vous devenez plus capable de prédire les effets que ces changements auront sur le système.

Pour l’instant, néanmoins, vous n’avez pas cette expérience… au moins pas avec ce jeu. Playtester par vous-même est votre premier acte de découverte. Et comme vous découvrez, cela peut semblez comme si vous jeu voulait grandir dans une nouvelle direction, comme s’il avait une vie propre. Si vous sentez ça, allez y et écoutez votre jeu. Voyez où le processus de découverte vous mène.

Homeplay

As the nature of the work at this stage is solo, you do not have to post anything on the forums. Work alone until Monday, at which point we will start involving others.

Before Monday, August 10, noon GMT, create a playable prototype of your game. You may find it useful to review the section of Level 4 on prototyping. Remember that you can make a prototype in about 15 minutes – it doesn’t have to be pretty and it doesn’t even have to be complete (yet), but it does need to be at the point where you can sit down and play it by yourself.

Then, play the game by yourself, at least once. In your idea notebook, write down any problems you encountered or questions that you ran into. Trust me, no matter how obvious the things are that you need to fix, you will forget them if you don’t write them down.

Finally, write down the rules once your game is at least somewhat playable. This is also for your own reference, so that you do not forget.

Article précédent : Niveau 10 – Aperçu du projet de design

Article suivant : Niveau 12 – Jouer avec des designers

 

1 Le terme « bug testing » est emprunté à l’informatique ; où un « bug » est une erreur dans le code.

2 Le terme « focus testing » se réfère au terme « focus group » ; qui est un échantillon représentatif du public cible d’un produit ou d’un service.

3 Le terme « usability testing » signifie « test d’utilisabilité » et est plus connu sous le nom de « test utilisateur ».

4 Le terme « Balance testing » signifie « Test d’équilibrage ».

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>