Little Blog Story

Game-Design & Modding le blog de belzaran.

Articles taggés avec ‘test’

Aujourd’hui, je vais faire honneur à mes testeurs en analysant les différentes sessions de tests afin de mettre en avant leur rôle essentiel dans le développement d’un projet (surtout si on le développe seul, les avis extérieurs sont d’autant plus importants).

Quels testeurs ?

Avant de dire “je dois faire des tests”, je me suis posé la question “qui pourrait tester ?”. Trouver des testeurs n’est pas forcément si simple, car il est bon de les garder un minimum d’un test à l’autre et d’éviter un turnover très important. Très vite, par l’intermédiaire de ModDB, des personnes se sont proposées spontanément. Très vite, j’ai éliminé ce genre de profil pour plusieurs raisons. La première est la barrière de la langue : j’avais besoin de francophones afin qu’ils puissent expliquer clairement leurs idées, critiques ou conseils. La deuxième est le côté trop “fan” de ces personnes : quand quelqu’un est toujours fan de ce que vous faites, il risque de manquer d’esprit critique lorsqu’il jouera ou, pire, d’être très déçu par une version inaboutie très loin de leurs attentes. Je n’exclus par contre pas de les inclure dans des versions beta beaucoup plus proches d’une version finale.

Je me suis donc tourné rapidement vers les communautés francophones que je fréquentais : WeFrag, Mapping-Area et Unreal.fr. Avec des fortunes diverses (on ne peut pas dire que WeFrag se soit porté très volontaire sur le coup…), j’ai commencé avec une base de quelques testeurs (entre 4 et 8 selon les tests) qui a légèrement évolué tout en gardant un noyau dur, essentiel pour accompagner un minimum le projet et suivre son évolution. Plusieurs profils se sont alors dégagés naturellement, certains testeurs cumulant plusieurs profils :

  1. Le Gamer : il appréhende le jeu comme tel, de façon global. Il constitue la cible finale et donne des ressentis : j’aime/j’aime pas, je me suis amusé/ennuyé, etc. Essentiel évidemment.
  2. Le Level-Designer : il appréhende le jeu sur l’aspect graphique et technique : fonctionnement des scripts, qualité des lumières, intérêt d’un son à tel endroit.
  3. Le Moddeur ou Game-Designer : il appréhende le jeu de façon globale en incluant l’aspect promotion du jeu et en faisant des remarques sur la cible visée (typiquement le genre de gars qui fait tester le jeu à sa copine ou à sa petite cousine…) ou encore en critiquant le background.

Si chaque type de testeur est évidemment important, chacun va avoir tendance à être pointilleux sur des aspects très différents. L’un va dire que les textures du tabouret de la salle deux sont mal alignées, l’autre va reprocher que le mana ne se charge pas assez vite.

Un autre aspect important est que les testeurs sachent s’exprimer correctement. Si un testeur commence à dire trop souvent “je sais pas comment expliquer”, il ne faut pas hésiter à laisser tomber. Être concis est une qualité, certes, mais un testeur exhaustif est un don du ciel. Quitte à faire une synthèse derrière (ce que je fais systématiquement).

Fonctionnement des tests

Lorsque je lance un test, voilà comment je procède (en tout cas maintenant que je sais que c’est ce qu’il faut faire !) :

  1. Compiler le jeu
  2. Tester le jeu
  3. Uploader le jeu
  4. Downloader le jeu
  5. Installer le jeu
  6. Re-tester le jeu

Cela demande pas mal de temps mine de rien, surtout si l’une des étapes est défaillante. Par exemple, si l’étape 6 est défaillante, mieux vaut tout recommencer. Après toutes ces péripéties, il reste à prévenir les testeurs que la version est prête. Je joins systématiquement un fichier afin d’expliquer un peu à quoi ressemble un peu la version et les points sur lesquels je souhaite qu’ils se focalisent. Il va sans dire que certains testeurs ne lisent pas les instructions et lancent le jeu directement…

Voilà un exemple de ce qui est envoyé (deuxième test) :

Episode : Freyr Tutorial
Version : Beta 1.00
Description : Tutorial à tester

Points particuliers à observer et tester :
- Arriver à terminer le niveau
- Durée et pertinence des cinématiques (ou de leur absence)
- Observation de bugs éventuels (sonores, graphiques et de gameplay)
- Ergonomie du niveau (facilité de déplacement, collisions, etc.)
- Ergonomie des contrôles
- Toute autre remarque en termes de gameplay/idées/propositions graphiques
- Tout faire pour essayer de pourrir le jeu
Et surtout : quel a été l’enchaînement d’actions qui a permis de sortir de la salle ? (erreurs comprises) L’important est d’avoir un compte-rendu précis du cheminement qui permet au final de réussir. Que ce soit fait rapidement ou pas.

Bugs connus :
- La deuxième salle (hall du château) n’est pas terminée
- Pas de fin de niveau automatique (le tutorial se termine quand on entre dans le deuxième château)
- Menu de démarrage bancal
- Système de contrôle imparfait
- Les sous-titres ne sont pas centrés
- Pas d’animations sur les chaînes pour le pont-levis
- Le jeu se lance en fenêtré en résolution 1024×768. Pour passer en fullscreen : « alt+tab » et pour changer la résolution « TAB (ouvre la console) » puis « SETRES 1280×1024 » (par exemple pour une résolution de 1280×1024)

Changements depuis la dernière version :
- Système de contrôles revu
- Système de mana implanté
- Correction du bug qui obligeait à activer un élément AVANT d’aller sur un bouton
- Double saut supprimé
- Plus de dommages quand on utilise le mode FEU
- Ajouts de sons lors d’évènements (porte qui s’ouvre, plateforme qui bouge…)

Contrôles :
Left Mouse : Feu
Right Mouse : Eau
Left Shift : Air

Le fait d’annoncer les changements depuis la dernière version permet aussi de signaler aux nouveaux testeurs ce qui a été ajouté et supprimé, afin d’éviter qu’ils ne proposent des features déjà testées et abandonnées par exemple.

Suite à cela, chaque testeur me fait un compte-rendu plus ou moins explicite (certains font 5 pages, d’autres sont des screenshots commentés). Je prends le temps de les digérer, je rédige un compte-rendu que j’envoie aux testeurs. Dans cette note, j’écris aussi bien ce que m’ont dit mes testeurs, mais également ce que je vais prendre en compte et les idées que je ne retiendrai pas. L’avantage d’envoyer un compte-rendu global c’est que certains testeurs y réagissent ensuite, me permettant parfois d’affiner mes idées.

Un exemple précis : un testeur a rédigé un compte-rendu où il hurlait (métaphoriquement) contre le système de mana. Globalement, son test donnait l’impression qu’il aimait le jeu mais que le système de mana lui gâchait son expérience. Comme le mana me gênait un peu moi-même (j’utilisais souvent des cheats codes pour le court-circuiter), j’avais décidé de l’alléger un peu de multiples façons. J’ai donc, dans le compte-rendu, annoncé cette intention. Deux mails de testeurs m’ont été envoyé, disant que c’était une erreur. En effet, le système de mana pénalise les joueurs maladroits ou qui utilisent les éléments avec excès. En bref, le mana oblige aussi à réfléchir et à ne pas tout tenter jusqu’à ce que quelque chose fonctionne.

Le compte-rendu a aussi pour but de montrer à certains testeurs que leur avis est minoritaire. Non pas pour les descendre, mais il est important pour tout le monde de comprendre qu’un jeu doit plaire à plusieurs personnes et n’est jamais parfait pour un individu donné (ni même moi).

Le background

Je vais maintenant parler de certains aspects où l’apport des testeurs a été primordial. Les exemples seront donc on ne peut plus concrets !

Je reviendrai plus tard sur la genèse complète du background de Little God Story, mais l’impact des testeurs a été considérable. Au départ, j’ai créé un personnage : Little God. L’idée est qu’il ressemble à un viking, il est bourru, un peu comme un Nain. Je souhaitais ensuite écrire un scénario basé sur une quête des quatre éléments avec un background nordique. Au départ, rien n’est écrit de concret alors que les premiers tests démarrent.

Sur le deuxième test, voilà ce que m’a dit un testeur :

Pour moi, il apparaît très clairement que tu t’es posé beaucoup de questions quant au gameplay, mais en fait pas encore trop, derrière, sur son background. Et je pense très sincèrement que tu devrais procéder à l’inverse pour mieux asseoir l’ambiance et les principes de base de ton projet, afin de développer ensuite un gameplay en rapport avec.

Outch ! Et ça continue :

Plus terre à terre et en phase avec ce que tu présentes dans cette seconde beta : visuellement, tout d’abord, je trouve que le visuel que tu mets en place ici, – bien que déjà assez agréable – ne colle pas avec l’idée de ton mod. Tout cela fait plutôt médiéval (et plus proche d’ailleurs du haut moyen-âge) que de la culture viking. Quand au côté « divin », il me semble complètement passer à la trappe.

Ce genre de discussion s’est mené avec deux testeurs sur l’aspect Viking de mon jeu. J’ai tenté à de nombreuses reprises de coller Little God Story avec cet aspect-là, mais mes testeurs m’ont poussé à me rendre compte, simplement, que les Vikings n’avaient pas de château… Finalement, je me suis aperçu que pour enrichir et rendre crédible mon background, mieux valait le concevoir de A à Z. Cette souplesse me permettrait ensuite de faire ce que je souhaitais.

Le gameplay

Outre les ajustements de gameplay (tel que l’équilibrage), les testeurs apportent des briques bien plus importantes à l’édifice. Les premières versions de tests présentées ne possédaient qu’une part minime du gameplay de Little God Story aujourd’hui. Cela se limitait aux changements de capacités du personnage selon l’Elément utilisé (Feu = plus vite, Air = plus haut), aux interrupteurs et au système pierre/ciseau/papier (l’Eau tue le Feu, le Feu tue l’Air, etc.).

Comme dit précédemment, je me suis rapidement limité sur le gameplay afin d’éviter d’être trop ambitieux et de me brûler les ailes. Malheureusement, rapidement, j’ai du me confronter à mes testeurs qui (bien sûr) n’étaient pas du même avis :

Il faudra, je pense, que le joueur se serve de ses Runes pour déclencher des mécanismes d’une façon un peu plus naturelle qu’un simple interrupteur.

Ou encore :

Un petit coté Mirror’s Edge peut être sympa. En tout cas rajoute de la diversité.

Dès les premiers tests, avec une map de 10/15 minutes, le besoin de dynamisme se fait sentir. Comme il est généralisé chez TOUS les testeurs, je comprends que je vais être obligé d’ajouter des armes dans le jeu. Rapidement, je conçois l’arme de feu (la plus logique en fait) qui détruit des petits morceaux de bois. J’intègre ce principe dans les niveaux existants mais pas encore aux énigmes proprement dites. Plus tard, j’ajoute également l’arme d’air, mais ça reste encore un gadget pas très clair (l’arme fait bouger des objets à distance). Le travail demandé par ces ajouts est finalement relativement faible comparé au plaisir de jeu, bien plus intéressant.

J’ajoute un niveau entier supplémentaire avec des énigmes prenant en compte ces nouvelles armes et relance un test. Cette aspect dynamique est bien accueilli par les joueurs bien que pas évident (c’est plus facile de repérer un gros bouton vert qui brille plutôt qu’un bout de bois au plafond). Vient alors une remarque extrêmement pertinente :

Encore une fois, je pense que l’essentiel des problèmes que je te remonte est dû au fait que tu ne prends pas le temps de poser d’abord les choses sur papier.

Ce problème est évident car, à ce moment-là, je n’avais pas encore défini ce que feraient les armes d’Air et d’Eau, ni même s’il y aurait deux types d’attaques différentes (une sorte de tir secondaire). L’idée est d’arrêter de bloquer sur le principe de la réalisation. De ne plus se poser la question “est-ce que j’arriverai à faire ça ?” mais “qu’est-ce que je pourrais faire comme puzzle si le joueur peut faire ça ?” Il est essentiel d’avoir au moins en tête les features que l’on va implanter afin de prévoir un espace dans le tutoriel pour les intégrer, ainsi que l’agencement des puzzles. En pointant le doigt là-dessus, mes testeurs m’ont permis de comprendre que mon game-design était encore un peu léger.

La promotion

Certains m’ont déjà posé la question sur l’avenir de Little God Story. En gros trois questions sont les plus fréquentes :

  • Quand est prévue la sortie ?
  • Y’aura-t-il une démo ?
  • Sera-t-il payant ?

J’avoue ne pas avoir trop de réponse à ces questions. J’ai clairement envie de sortir une démo, mais je ne suis pas encore certain de le faire. FPS Terminator a eu droit à une démo qui a clairement douché l’enthousiasme d’un paquet de joueurs. Il lui manquait clairement une série de tests privés qui aurait corrigé une grande partie de ses défauts. Même si j’espère que ce jeu progressera, j’ai peur que beaucoup de joueurs s’en désintéressent (personnellement, je n’ai pas fait l’effort d’installer la version corrigée, javoue. J’avais envisagé de sortir une démo de Little God Story a un moment où aucun système de checkpoints n’avait été implanté. Mes testeurs m’ayant copieusement insulté sur ce point-là, cela paraissait impensable de le faire… Il n’est pas évident de se retenir de présenter son travail au plus grand nombre. Sortir une démo UDK, c’est s’assurer quelques articles sur les sites spécialisés…

Les tests permettent également de tester l’impact du jeu sur des publics pas forcément attiré à l’origine par le jeu :

Tout d’abord je dois avouer que le mod ne m’attirait pas plus que ça. (…) Toutefois je ne regrette pas d’avoir essayer LGS, et j’ai été surpris par le jeu. Agréablement surpris, j’entends.
Je ne cache pas qu’il y a eu des réactions inverses. Certains testeurs attendaient beaucoup du jeu et ont été très déçus par des versions encore peu abouties.
Comme dit précédemment, certains testeurs n’ont pas hésité à tester le jeu sur des publics plus larges (moi aussi d’ailleurs). Ceci a permis de préciser un peu la cible que je visais (qui n’est donc pas du tout les casual gamers !).

La version de test

Si choisir une version pour une release est très difficile, il n’est pas évident non plus de décider quand est-ce que la version présentée aux testeurs est suffisante. En effet, il ne faut pas faire trop de tests au risque de lasser les testeurs (qui joueraient toujours aux mêmes niveaux) et ne pas en faire trop peu afin de les impliquer dans le projet. Les tests sont très motivants pour un développeur car ils constituent des retours qui poussent à faire mieux (un peu comme un bon coup de pied au cul).

La première version de test que j’ai envoyé a été un fiasco. D’abord parce-qu’elle avait un bug très embêtant : le puzzle était orienté entièrement vers l’ouverture de la porte qui permettrait de partir. Or, cette porte n’avait pas de modèle de collision et permettait donc au joueur de finir le puzzle sans le faire réellement. Un bug inadmissible en soi, qui prouvait que je n’avais pas moi-même testé mon niveau dans cette optique. Deuxième grosse erreur : je n’ai présenté qu’un seul puzzle. En ne faisant pas de tutoriel, ni même de puzzle simple pour introduire ce qui reste actuellement l’un de puzzles les plus complexes, mes testeurs se sont arraché les cheveux. Ce qui nous mène directement au deuxième test.

Le deuxième test comportait le niveau “tutoriel”. Il démarrait au début de l’aventure et permettait d’apprendre petit à petit les pouvoirs. Son aspect graphique était rudimentaire (voir pire par moment) et le tutoriel mêlait mini-cinématique et sous-titres pour expliquer la marche à suivre. Au niveau du gameplay, il introduisait la jauge de mana (première feature à apparaître d’après les remarques des testeurs) et améliorait le système de contrôle. Quelques sons faisaient leur apparition, rendant le jeu plus crédible.

Le troisième test comportait ce même niveau “tutoriel” avec de fortes améliorations graphiques et l’ajout de nouvelles pièces, permettant d’obtenir les pouvoirs petit à petit. On peut noter également la personnalisation du HUD, l’ajout d’un journal de bord (pour se souvenir des instructions précédentes), de l’affichage de l’objectif en cours, de l’ajout de musique et de l’ajout de l’arme de Feu (lancer de boules de feu). Cette version, si elle modifiait relativement peu le gameplay pur (le lancer de boules de feu étant assez accessoire à ce moment-là) a donné aux testeurs une vision du jeu beaucoup plus agréable. Les graphismes étaient plus variés et plus beaux. L’ensemble était plus ergonomique et facile à jouer. Enfin, la suppression des cinématiques a atténué la lourdeur de l’ensemble. Pour info, je pensais à ce moment sortir cette version en démo publique.

Le quatrième test avait pour but de prolonger l’expérience en proposant le deuxième niveau (et donc des puzzles plus compliqués). Bien que relativement concluante, cette version a permis de pointer les soucis du premier tutoriel dès que les énigmes deviennent plus complexes. En revanche, de gros efforts ont été faits avec l’ajout de voix in-game qui donnent une réelle existence à Little God (et quelqu’un d’autre. Mais… Surprise !) et améliore le background qui était beaucoup trop léger. Il ajoutait également l’indispensable système de checkpoint. Bien qu’encore insuffisant, il supprimait ce qui était la partie la plus frustrante de la version précédente : devoir tout recommencer pour une maladresse… Cette version ajoutait également l’arme d’Air. A ce moment-là, cette arme était trop peu développée. Elle ne faisait aucun bruit, aucune animation à l’écran, aucun sprite ou particule… Il aurait été préférable qu’elle soit plus avancée avant de la faire tester. Ce quatrième test aurait mérité une ou deux semaines de développement de plus afin d’éviter les soucis qu’ont rencontré les joueurs.

Les améliorations que je cite dans toutes ces versions ont été proposées dans la majorité des cas par les testeurs. Soit directement (suppression des cinématiques), soit indirectement (manque d’ambiance sonore, background…) inexistant…). Le nombre d’améliorations à apporter pour le prochain test sont assez importantes. Je n’ai aucune idée de quand je le ferai, ni de ce qu’il contiendra exactement. Je décide de faire un test quand je considère que le jeu a pas mal évolué et qu’il faut tester ce qui a été fait afin d’être sûr de ne pas perdre son temps sur des puzzles ou features bancales.

Conclusion

Cet article est comme un cri d’amour pour les testeurs et je pense que tout le monde l’aura remarqué. J’avais déjà signalé leur rôle prépondérant dans le post-mortem d’Unreal Safari, je le confirme ici. Certes, les testeurs ont tendance à doucher l’enthousiasme d’un développeur de par leurs nombreuses requêtes et critiques. Il faut aussi prendre en compte qu’ils ne limitent pas leur conseil à la faisabilité. Nombre de fois, ils proposent des features que je considère comme infaisable (par moi). Et parfois, quelques mois ou semaines plus tard (et même quelques jours plus tard !), ces features sont (plus ou moins bien) implantées. Car les possibilités de plaisir de jeu qu’elles véhiculent sont énormes…

Je termine en rappelant que Little God Story a encore besoin de testeurs pour de nombreux mois (années ?) et que la communauté WeFrag ne m’a apporté à ce jour qu’un seul testeur ! Si vous voulez des jeux qui vous ressemblent, il faut savoir s’impliquer. De là découle ma conclusion : si vous avez un jeu/mod en préparation et que vous cherchez des testeurs, n’hésitez pas à me demander, je me ferai un plaisir de participer !

Pour ceux qui veulent tester ou faire tester un jeu/mod, voilà un article intéressant (en anglais) sur le sujet : http://www.moddb.com/tutorials/mod-testers-handbook

Autres liens :

http://www.moddb.com/games/fps-terminator

pageTracker._initData(); pageTracker._trackPageview(); } catch(err) {}