04-09-2020, 09:52 AM
[Brouillon] Méthode pour tester un jeu :
Vous êtes arrivé à un moment clé du développement de votre jeu : vous venez de rajouter une mécanique principale, ou vous êtes sur le point de le sortir officiellement. C’est à ce moment là qu’un test s’impose pour voir ce qui va (ou pas), si vous allez dans la bonne direction (ou pas), si des idées peuvent émerger des gens qui vous entourent.
En tant que développeur vous avez vous même déjà testé les fonctionnalités de votre jeu ; en tant que testeur vous avez peut-être eu accès à une version précédente du jeu. À ce moment là il faut repartir de zéro, essayer de rendre le jeu avec un nouveau regard et le voir dans son ensemble et non seulement comme une suite de fonctionnalités. Ne faites pas tester votre jeu trop souvent, cela prend du temps aux testeurs bénévoles, et ils auront une vision déjà préfabriquée du jeu que vous leur avez déjà présenté.
I. Préparation
Avant toute chose il faut se préparer à tester le jeu. Il faut être sûr d’avoir :
- un espace de travail adéquat ;
- du temps devant soit ;
- son éditeur de texte favori à porté (d’un Alt+Tab).
Un espace de travail adéquat car tester un jeu ce n’est pas jouer à un jeu. C’est un vrai travail à fournir qui induit la rédaction d’un compte-rendu à la fin de la session. Donc il faut être dans un lieu calme où vous ne serez pas perturbé, et il faut avoir une posture de travail (derrière un ordinateur de bureau) et non pas avachi sur un canapé, aucun autre application d’ouvertes pour éviter les perturbations extérieures. Pour tester un jeu il faut être curieux (car c’est beaucoup de : « je vais essayer ça voir ce que ça donne »), rigoureux (car il faut tester plein de trucs, dans plein de configurations) et persévérant (si on test de nouveau un jeu que l’on connaît).
Du temps devant soit car il faut pouvoir faire le tour du jeu et en plus rédiger ses remarques pour enfin publier ça à l’auteur. En tant qu’auteur vous devez d’ailleurs estimer le temps d’une session de test de votre jeu, ou de la partie du jeu que vous avez demandé à tester, pour permettre à vos testeurs de planifier au mieux leur emploi du temps en fonction du temps dont ils disposent. Il est très fortement déconseillé de quitter une session de test avant l’envoi du compte-rendu sous risque d’oublier certains aspects globales, faire des remarques redondantes, ne pas pouvoir terminer ultérieurement le test.
Son éditeur de texte favori avec si possible une coloration syntaxique ou au moins une manière de différencier facilement les différentes parties de votre compte-rendu de test. Si possible n’avoir que le logiciel de traitement de texte et le logiciel simulant le jeu (votre navigateur par exemple) d’ouvert, pour pouvoir aisément passer de l’un à l’autre (avec un Alt+Tab). Pensez dès le début à sauvegarder votre compte-rendu vierge à un endroit spécifique (et évident) et à enregistrer régulièrement vos modifications.
II. Structure du compte-rendu
Structurez dès le début votre fichier de compte-rendu en plusieurs parties :
- Première impression ;
- Soucis techniques, avis objectifs ;
- Idées, avis subjectifs ;
- Avis global, +, -, améliorations.
Tout au fil de la session de test il vous faudra remplir ces sections du compte-rendu dès que quelque-chose vous vient à l’esprit pour ne rien oublier. En voici une explication plus détaillée.
Première impression :
Rendez-vous sur le lien que l’on vous a fourni pour tester le jeu, et à partir de ce moment là le test commence réellement.
Ce qu’il faut noter immédiatement c’est la première impression concernant ce tout premier aperçu du jeu (que ce soit la page d’accueil ou le jeu directement). Est-ce que vous voyez clairement où doit aller votre premier clic ? Quel est le style du jeu ? Quel univers vous imaginez ? Est-ce que c’est lisible, bien agencé ? Est-ce que vous avez des soucis d’affichage ? Est-ce agréable ? Est-ce que vous vous y retrouvez ? Est-ce que vous comprenez ce qu’il s’y passe ?
La deuxième chose à noter, si jamais vous n’arrivez pas directement en jeu, c’est la facilité à accéder au jeu à partir du lien qu’on vous a fourni (inscription ou téléchargement). Est-ce rapide et intuitif ? Avez-vous rencontré des problèmes ? Vous êtes vous un peu perdu ?
Soucis techniques, avis objectifs :
Dans cette section il faudra noter sous format de liste à puce (pour faciliter la relecture) tous les problèmes de fonctionnement ou d’affichage du jeu. Les problèmes de jouabilité, de manière très objective. Par exemple les textes qui sortent de leur contenant, les images qui ne s’affichent pas, une quête que vous n’avez pas compris, un bouton non fonctionnel ou ne faisant pas ce qu’il dit faire, les fautes d’orthographe, l’ergonomie, les problèmes liés à la résolution de l’écran ou les messages d’erreur en rouge dans la console (F12). En tant qu’auteur il peut d’ailleurs être intéressant de ponctuer son code de log (tel que console.log) pour afficher à l’utilisateur ce qui se passe. D’autant plus utile si il y a un soucis, vous pourrez plus facilement le comprendre grâce à ce log fournit par le testeur.
Il est fortement conseillé de regrouper ces bugs par lieu d’apparition (menu, page d’accueil, page de construction, informations sur le personnage). Cela permettra plus rapidement au créateur de savoir où cela se trouve et de le corriger aisément. Ce conseil s’applique également pour la section suivante.
Idées, avis subjectifs :
Ici vous rangerez les questionnements du style : « pourquoi as-tu fais ça ? » ou « est-ce qu’il ne vaut mieux pas faire ainsi ? » etc. C’est également ici que vous donnerez votre avis personnel concernant le jeu, le concept, la réalisation, l’aspect visuel, le choix de tel ou tel élément, l’équilibrage, etc. Vous pourrez également proposer de rajouter ou d’enlever des mécanismes de jeu, de simplifier certains ou de complexifier d’autres.
Cette partie est très utile pour le créateur, mais gardez en tête que c’est son œuvre personnelle et qu’il en a une vision prédéfinie, peut-être différente de la votre. Demandez des explications sur le pourquoi des choses, ses choix, mais ne soyez pas déçu qu’il ne suivent pas vos idées si elles diffèrent de sa vision du jeu. Il faut proposer son point de vue mais ne pas l’imposer.
Avis global, +, -, améliorations :
Dans la suite logique de vos idées et vos avis subjectifs, il est ensuite question de rassembler vos pensées pour fournir une appréciation d’ensemble du jeu. D’abord en deux trois phrases sur le concept, les mécanismes, l’ambiance, la fonctionnalité ou autre qui vous a marqué, puis en détaillant les quelques points positifs et négatifs que vous avez soulevez. Expliquez en quoi ces points sont bénéfiques ou néfastes pour le jeu, et proposez une ou deux manières de les améliorer dans le second cas. Prenez plus de temps concernant les gros points négatifs, en écrivant un petit paragraphe à chaque fois, pour aider à améliorer le jeu.
III. Répondre au formulaire
Si l’auteur vous a envoyé un formulaire de questions à répondre pour le test final de son jeu, ce n’est qu’ensuite qu’il faut l’ouvrir et le lire. En général il est bourré de questions, donc le lire en amont ne vous permettra pas de vous souvenir des questions. Mieux vaut le prendre au final et répondre succinctement aux questions, en ayant ainsi l’ensemble du jeu en tête. N’hésitez pas à copier des passages de votre compte-rendu dans ce formulaire si cela correspond à la question.
Si le test est sur une mécanique uniquement ou sur une seule partie du jeu, alors mieux vaut ouvrir le questionnaire et répondre à la demi-douzaine de questions directement.
Chaque test peut avoir un but différent et cibler un aspect seul du jeu. En tant que créateur il faut donc en amont expliquer l’objectif spécifique de ce test avant que vos testeurs se lancent corps et âme dans votre projet.
Voici cependant quelques idées générales de structuration / questions pour son formulaire :
- Nom du jeu, lien pour y accéder, remerciement, manière de retourner ce formulaire.
- Réfléchir si on veut un système de notation, et lequel. On pourrai penser à un vote de « non à oui » avec comme choix « non et en plus... ; non mais quand même... ; oui mais cependant... ; oui et en plus... ». Le tout est de ne pas avoir un choix neutre (donc un nombre pair de réponse, de 1 à 4 ou de 1 à 6 si vous préférez).
- Traiter si possible toutes les données à choix fermés sous forme de chiffre pour pouvoir les exploiter derrière plus facilement et globalement. Faire un questionnaire à choix multiple si possible. Vous pouvez même demander de répondre sur une seule ligne à chaque fois ou dans une cellule d’un tableau ou sur un formulaire en ligne, dans le but d’automatiser le traitement des réponses.
- Numérotez chaque question (et chaque sous question) pour pouvoir y faire référence plus tard si nécessaire.
0. Votre pseudo ?
1. Quel a été votre première impression ?
2. Quelle était votre résolution d’écran ?
3. Quels bugs majeurs avez-vous rencontré, et quand cela s’est-il produit ?
4a. Combien de temps avez-vous joué ?
4b. Avez-vous terminé une partie (pour un jeu solo) ?
4c. Avez-vous gagné (quel score) ?
5. Pourquoi avoir arrêté de jouer ?
6a. Réessayerez-vous demain ?
6b. Pourquoi ?
7a. En parlerez-vous à vos amis joueurs ?
7b. Pourquoi ?
8. Est-ce que vous êtes ma cible ? (question à préciser en fonction du type de jeu réalisé)
9a. Quels ont été pour vous les points positifs ?
9b. En quoi ?
10a. Quels ont été pour vous les points négatifs ?
10b. En quoi ?
10c. Comment améliorer ces points ?
11. Qu’est-ce qu’il manque cruellement dans le jeu ?
12. Qu’est-ce qui est pénible à faire dans le jeu ?
13. Comment définiriez-vous le jeu en deux phrases ?
14. Qu’avez-vous pensé du tutoriel ?
15. Zone libre de parole.
Ensuite selon le type de jeu vous pouvez proposer de noter (et de détailler) :
- la narration
- les effets visuels
- le background
- les mécaniques principales du jeu (les nommer)
- l’interface graphique (gui)
- les images
- les musiques
- les mécaniques de jeu mises en place pour avoir de l’interaction avec les autres (chat, forum, vente, combat, traités, partage des ressources, messages privés, etc.)
- la diversité d’évènements
- la rejouabilité (pour un jeu solo)
- le prix ou la valeur des choses
- l’âme des pnj
- la progression
- l’équilibrage de manière générale
IV Finalement
Après cette longue session de test, il vous faudra être disponible pour l’auteur au cas où il vous contact pour répondre à vos questions ou pour un test ultérieur. Échangez avec lui sur les points en désaccord pour bien cerner vos différents. Exposez votre point de vue mais entendez également le sien. Rebondissez sur ce qu’il vous répond pour que, une fois la démarche comprise, vous puissiez l’aiguiller sur votre ressenti.
C’est une bonne chose de se proposer à tester les jeux car c’est gratifiant de se dire que l’on participe à un autre projet. Que grâce à nous un projet se bonifie. Ça permet également l’entre-aide et potentiellement qu’on nous rende la pareil. Et ça peut vous apporter des idées ou une vision des choses différentes pour vos projets personnels.
Alors n’hésitez plus, proposez-vous et bon test !
Vous êtes arrivé à un moment clé du développement de votre jeu : vous venez de rajouter une mécanique principale, ou vous êtes sur le point de le sortir officiellement. C’est à ce moment là qu’un test s’impose pour voir ce qui va (ou pas), si vous allez dans la bonne direction (ou pas), si des idées peuvent émerger des gens qui vous entourent.
En tant que développeur vous avez vous même déjà testé les fonctionnalités de votre jeu ; en tant que testeur vous avez peut-être eu accès à une version précédente du jeu. À ce moment là il faut repartir de zéro, essayer de rendre le jeu avec un nouveau regard et le voir dans son ensemble et non seulement comme une suite de fonctionnalités. Ne faites pas tester votre jeu trop souvent, cela prend du temps aux testeurs bénévoles, et ils auront une vision déjà préfabriquée du jeu que vous leur avez déjà présenté.
I. Préparation
Avant toute chose il faut se préparer à tester le jeu. Il faut être sûr d’avoir :
- un espace de travail adéquat ;
- du temps devant soit ;
- son éditeur de texte favori à porté (d’un Alt+Tab).
Un espace de travail adéquat car tester un jeu ce n’est pas jouer à un jeu. C’est un vrai travail à fournir qui induit la rédaction d’un compte-rendu à la fin de la session. Donc il faut être dans un lieu calme où vous ne serez pas perturbé, et il faut avoir une posture de travail (derrière un ordinateur de bureau) et non pas avachi sur un canapé, aucun autre application d’ouvertes pour éviter les perturbations extérieures. Pour tester un jeu il faut être curieux (car c’est beaucoup de : « je vais essayer ça voir ce que ça donne »), rigoureux (car il faut tester plein de trucs, dans plein de configurations) et persévérant (si on test de nouveau un jeu que l’on connaît).
Du temps devant soit car il faut pouvoir faire le tour du jeu et en plus rédiger ses remarques pour enfin publier ça à l’auteur. En tant qu’auteur vous devez d’ailleurs estimer le temps d’une session de test de votre jeu, ou de la partie du jeu que vous avez demandé à tester, pour permettre à vos testeurs de planifier au mieux leur emploi du temps en fonction du temps dont ils disposent. Il est très fortement déconseillé de quitter une session de test avant l’envoi du compte-rendu sous risque d’oublier certains aspects globales, faire des remarques redondantes, ne pas pouvoir terminer ultérieurement le test.
Son éditeur de texte favori avec si possible une coloration syntaxique ou au moins une manière de différencier facilement les différentes parties de votre compte-rendu de test. Si possible n’avoir que le logiciel de traitement de texte et le logiciel simulant le jeu (votre navigateur par exemple) d’ouvert, pour pouvoir aisément passer de l’un à l’autre (avec un Alt+Tab). Pensez dès le début à sauvegarder votre compte-rendu vierge à un endroit spécifique (et évident) et à enregistrer régulièrement vos modifications.
II. Structure du compte-rendu
Structurez dès le début votre fichier de compte-rendu en plusieurs parties :
- Première impression ;
- Soucis techniques, avis objectifs ;
- Idées, avis subjectifs ;
- Avis global, +, -, améliorations.
Tout au fil de la session de test il vous faudra remplir ces sections du compte-rendu dès que quelque-chose vous vient à l’esprit pour ne rien oublier. En voici une explication plus détaillée.
Première impression :
Rendez-vous sur le lien que l’on vous a fourni pour tester le jeu, et à partir de ce moment là le test commence réellement.
Ce qu’il faut noter immédiatement c’est la première impression concernant ce tout premier aperçu du jeu (que ce soit la page d’accueil ou le jeu directement). Est-ce que vous voyez clairement où doit aller votre premier clic ? Quel est le style du jeu ? Quel univers vous imaginez ? Est-ce que c’est lisible, bien agencé ? Est-ce que vous avez des soucis d’affichage ? Est-ce agréable ? Est-ce que vous vous y retrouvez ? Est-ce que vous comprenez ce qu’il s’y passe ?
La deuxième chose à noter, si jamais vous n’arrivez pas directement en jeu, c’est la facilité à accéder au jeu à partir du lien qu’on vous a fourni (inscription ou téléchargement). Est-ce rapide et intuitif ? Avez-vous rencontré des problèmes ? Vous êtes vous un peu perdu ?
Soucis techniques, avis objectifs :
Dans cette section il faudra noter sous format de liste à puce (pour faciliter la relecture) tous les problèmes de fonctionnement ou d’affichage du jeu. Les problèmes de jouabilité, de manière très objective. Par exemple les textes qui sortent de leur contenant, les images qui ne s’affichent pas, une quête que vous n’avez pas compris, un bouton non fonctionnel ou ne faisant pas ce qu’il dit faire, les fautes d’orthographe, l’ergonomie, les problèmes liés à la résolution de l’écran ou les messages d’erreur en rouge dans la console (F12). En tant qu’auteur il peut d’ailleurs être intéressant de ponctuer son code de log (tel que console.log) pour afficher à l’utilisateur ce qui se passe. D’autant plus utile si il y a un soucis, vous pourrez plus facilement le comprendre grâce à ce log fournit par le testeur.
Il est fortement conseillé de regrouper ces bugs par lieu d’apparition (menu, page d’accueil, page de construction, informations sur le personnage). Cela permettra plus rapidement au créateur de savoir où cela se trouve et de le corriger aisément. Ce conseil s’applique également pour la section suivante.
Idées, avis subjectifs :
Ici vous rangerez les questionnements du style : « pourquoi as-tu fais ça ? » ou « est-ce qu’il ne vaut mieux pas faire ainsi ? » etc. C’est également ici que vous donnerez votre avis personnel concernant le jeu, le concept, la réalisation, l’aspect visuel, le choix de tel ou tel élément, l’équilibrage, etc. Vous pourrez également proposer de rajouter ou d’enlever des mécanismes de jeu, de simplifier certains ou de complexifier d’autres.
Cette partie est très utile pour le créateur, mais gardez en tête que c’est son œuvre personnelle et qu’il en a une vision prédéfinie, peut-être différente de la votre. Demandez des explications sur le pourquoi des choses, ses choix, mais ne soyez pas déçu qu’il ne suivent pas vos idées si elles diffèrent de sa vision du jeu. Il faut proposer son point de vue mais ne pas l’imposer.
Avis global, +, -, améliorations :
Dans la suite logique de vos idées et vos avis subjectifs, il est ensuite question de rassembler vos pensées pour fournir une appréciation d’ensemble du jeu. D’abord en deux trois phrases sur le concept, les mécanismes, l’ambiance, la fonctionnalité ou autre qui vous a marqué, puis en détaillant les quelques points positifs et négatifs que vous avez soulevez. Expliquez en quoi ces points sont bénéfiques ou néfastes pour le jeu, et proposez une ou deux manières de les améliorer dans le second cas. Prenez plus de temps concernant les gros points négatifs, en écrivant un petit paragraphe à chaque fois, pour aider à améliorer le jeu.
III. Répondre au formulaire
Si l’auteur vous a envoyé un formulaire de questions à répondre pour le test final de son jeu, ce n’est qu’ensuite qu’il faut l’ouvrir et le lire. En général il est bourré de questions, donc le lire en amont ne vous permettra pas de vous souvenir des questions. Mieux vaut le prendre au final et répondre succinctement aux questions, en ayant ainsi l’ensemble du jeu en tête. N’hésitez pas à copier des passages de votre compte-rendu dans ce formulaire si cela correspond à la question.
Si le test est sur une mécanique uniquement ou sur une seule partie du jeu, alors mieux vaut ouvrir le questionnaire et répondre à la demi-douzaine de questions directement.
Chaque test peut avoir un but différent et cibler un aspect seul du jeu. En tant que créateur il faut donc en amont expliquer l’objectif spécifique de ce test avant que vos testeurs se lancent corps et âme dans votre projet.
Voici cependant quelques idées générales de structuration / questions pour son formulaire :
- Nom du jeu, lien pour y accéder, remerciement, manière de retourner ce formulaire.
- Réfléchir si on veut un système de notation, et lequel. On pourrai penser à un vote de « non à oui » avec comme choix « non et en plus... ; non mais quand même... ; oui mais cependant... ; oui et en plus... ». Le tout est de ne pas avoir un choix neutre (donc un nombre pair de réponse, de 1 à 4 ou de 1 à 6 si vous préférez).
- Traiter si possible toutes les données à choix fermés sous forme de chiffre pour pouvoir les exploiter derrière plus facilement et globalement. Faire un questionnaire à choix multiple si possible. Vous pouvez même demander de répondre sur une seule ligne à chaque fois ou dans une cellule d’un tableau ou sur un formulaire en ligne, dans le but d’automatiser le traitement des réponses.
- Numérotez chaque question (et chaque sous question) pour pouvoir y faire référence plus tard si nécessaire.
0. Votre pseudo ?
1. Quel a été votre première impression ?
2. Quelle était votre résolution d’écran ?
3. Quels bugs majeurs avez-vous rencontré, et quand cela s’est-il produit ?
4a. Combien de temps avez-vous joué ?
4b. Avez-vous terminé une partie (pour un jeu solo) ?
4c. Avez-vous gagné (quel score) ?
5. Pourquoi avoir arrêté de jouer ?
6a. Réessayerez-vous demain ?
6b. Pourquoi ?
7a. En parlerez-vous à vos amis joueurs ?
7b. Pourquoi ?
8. Est-ce que vous êtes ma cible ? (question à préciser en fonction du type de jeu réalisé)
9a. Quels ont été pour vous les points positifs ?
9b. En quoi ?
10a. Quels ont été pour vous les points négatifs ?
10b. En quoi ?
10c. Comment améliorer ces points ?
11. Qu’est-ce qu’il manque cruellement dans le jeu ?
12. Qu’est-ce qui est pénible à faire dans le jeu ?
13. Comment définiriez-vous le jeu en deux phrases ?
14. Qu’avez-vous pensé du tutoriel ?
15. Zone libre de parole.
Ensuite selon le type de jeu vous pouvez proposer de noter (et de détailler) :
- la narration
- les effets visuels
- le background
- les mécaniques principales du jeu (les nommer)
- l’interface graphique (gui)
- les images
- les musiques
- les mécaniques de jeu mises en place pour avoir de l’interaction avec les autres (chat, forum, vente, combat, traités, partage des ressources, messages privés, etc.)
- la diversité d’évènements
- la rejouabilité (pour un jeu solo)
- le prix ou la valeur des choses
- l’âme des pnj
- la progression
- l’équilibrage de manière générale
IV Finalement
Après cette longue session de test, il vous faudra être disponible pour l’auteur au cas où il vous contact pour répondre à vos questions ou pour un test ultérieur. Échangez avec lui sur les points en désaccord pour bien cerner vos différents. Exposez votre point de vue mais entendez également le sien. Rebondissez sur ce qu’il vous répond pour que, une fois la démarche comprise, vous puissiez l’aiguiller sur votre ressenti.
C’est une bonne chose de se proposer à tester les jeux car c’est gratifiant de se dire que l’on participe à un autre projet. Que grâce à nous un projet se bonifie. Ça permet également l’entre-aide et potentiellement qu’on nous rende la pareil. Et ça peut vous apporter des idées ou une vision des choses différentes pour vos projets personnels.
Alors n’hésitez plus, proposez-vous et bon test !