Les serveurs de test sont, avouons-le, une sorte d’idée terrible qui ne cesse de se répandre dans l’espace MMO. Et plus je vieillis et plus je comprends l’industrie, plus je les considère comme inutiles au mieux et activement nuisibles au processus de test au pire.
C’était dans mon esprit lors de la dernière World of Warcraft résumé de l’interview, dans lequel il a été mentionné qu’une partie des problèmes avec Torghast n’a pas été trouvé par les personnes dans le test. Maintenant, le but ici n’est pas de faire glisser cette déclaration particulière (qui bien sûr des sons comme c’est manifestement faux si vous prêtiez attention aux commentaires réels de la bêta, mais peu importe) mais plutôt à regarder une partie de la philosophie des tests qui a été utilisée et comment cela a pu contribuer au problème.
Vraie conversation : une partie du problème ici réside dans le fait que les joueurs testent le système pour fournir des commentaires utiles. Et les joueurs ont des priorités différentes de celles des vrais testeurs, et vous ne pouvez pas simplement en libérer un tas et agir comme si vous aviez pris en charge une bonne session de test.
Prenons du recul. Qu’est-ce que les tests sont censés accomplir exactement ? Parce que dans les grandes lignes, il y a trois choses qui relèvent du large en-tête de « tests », et elles ont tendance à toutes être confondues en un seul travail. Dans les grandes lignes, nous pouvons considérer les tests comme ayant trois composants principaux :
- Test fonctionel: C’est le genre de test écrous et boulons, kick-the-pneus. Le serveur résiste-t-il à la charge ? Y a-t-il des bugs flagrants en cliquant sur quelque chose ? Pouvez-vous vous enfermer dans des boucles infinies, bonnes ou mauvaises ? Les systèmes fonctionnent-ils comme ils sont censés le faire ? C’est le processus de localisation des bogues et des problèmes existants et de s’assurer qu’ils sont traités et corrigés.
- Tests conceptuels: Est-ce amusant à faire ? La boucle de gameplay est-elle satisfaisante ? Les parties de la quête s’enchaînent-elles et ont-elles tout le tissu conjonctif approprié ? Les récompenses sont-elles proportionnelles au temps consacré ? L’objectif ici est de regarder au-delà des éléments immédiats de tout ce qui est testé et de le placer dans un contexte plus large, en particulier lors du référencement des documents de conception.
- Tests exécutifs: les différentes parties de ce contenu se chargent-elles de manière cohérente ? Est-ce que tout fonctionne correctement et vous donne une idée de la façon de jouer ? Comment ces systèmes interagissent-ils avec les autres ? C’est le chemin de base pour s’assurer que les systèmes et le contenu sont expliqués clairement et accessibles aux joueurs.
Vous pouvez voir le problème juste en regardant ces catégories, mais permettez-moi de le rendre explicite. La plupart de ces trucs sont des choses dont les joueurs ne se soucient pas vraiment. Personne qui joue sur un serveur de test ne se soucie de l’emplacement de ce nouveau contenu dans un document de conception, juste s’il est amusant ou non de jouer seul.
En fait, beaucoup de ces choses sont activement antithétique à la façon dont les joueurs sur les serveurs de test examinent tout cela. Oui, les joueurs veulent trouver des bugs et s’assurer qu’ils ne sont pas là, mais ils ne savent pas toujours non plus si quelque chose est un bug ou en fait comment il est censé fonctionner. Les joueurs peuvent vous dire si quelque chose est amusant ou non, mais ils ne peuvent pas vous dire s’il y a un raison quelque chose n’est pas amusant. Heck, la plupart des gens sur les serveurs de test sont principalement à essayer de nouveaux contenus, pas vraiment à test il.
Attention, je ne blâme pas les joueurs ici. Si vous n’êtes pas payé pour tester ce genre de choses, c’est par définition un loisir Plutôt qu’un travail, et il n’y a aucun moyen de reprocher aux joueurs de considérer un passe-temps comme quelque chose à faire pour s’amuser. Mais cela va naturellement affecter la qualité des tests, et cela va également affecter la façon dont les studios communiquent avec les joueurs.
Par exemple, disons qu’hypothétiquement un nouveau patch pour un jeu ajoute la construction de bateaux. Amusons-nous et prétendons que c’est, oh, Star Wars : L’Ancienne République. Il y a tout un système pour construire ses propres bateaux maintenant. Pourquoi? On s’en fout. Le fait est que vous construisez des bateaux.
Immédiatement, les joueurs commencent à revenir et expliquent que la construction de bateaux n’est pas amusante, que cela prend trop de temps et qu’il n’y a pas assez d’endroits pour utiliser les bateaux. Il y a plusieurs possibilités sur ce qui pourrait se passer ici. Il se peut, par exemple, que les mécanismes de construction de bateaux ne soient pas assez bien expliqués, de sorte que les joueurs ne sachent pas comment construire des bateaux correctement. Il se peut que le contenu du bateau ne soit pas encore prêt à être testé, donc les bateaux sont toujours limités dans leur utilisation. Il se peut que la construction d’un bateau soit censée être lente parce que vous êtes censé avoir terminé après avoir construit un bateau.
Mais en l’absence de ces informations, les joueurs vont retirer que la construction de bateaux n’est pas amusante et n’est pas utile. Et sans comprendre pourquoi les joueurs trouvent ce système peu amusant – parce que les joueurs n’ont pas une image complète de la façon dont les bateaux sont censés fonctionner – il est très facile de se contenter de rassurer les joueurs sur le fait qu’il volonté être amusant une fois qu’ils ont une image complète, même si les problèmes sont peut-être très réels et doivent être réellement résolus.
Maintenant, pour être juste, il y a certaines choses qui sont mieux testées avec des masses de joueurs. La stabilité du serveur, par exemple, est beaucoup plus facile à tester lorsque de nombreuses personnes se ruent sur vos serveurs avec une variété de vitesses de connexion et d’emplacements. De même, ouvrir le jeu dans la nature est souvent le meilleur moyen de s’assurer que les joueurs de différents niveaux de matériel peuvent exécuter le jeu de manière décente. C’est juste de la logique de base.
L’astuce est la différenciation. Les joueurs sont utiles pour tester ces choses lorsque le jeu a déjà subi la plupart des autres tests. Vous êtes presque sûr que les systèmes fonctionnent et sont stables. Les testeurs trouvent les choses amusantes. Le jeu se déroule comme il se doit. C’est pour cela que vous embauchez des testeurs, des personnes dont travail est en fait pour jouer au jeu et fournir des commentaires utiles.
Et c’est ici que les serveurs de test commencent à être activement malveillants. Car plus la fonction de testeur est transférée aux joueurs, plus il est tentant de lésiner sur le personnel QA qui peut effectivement faire le travail important de tester le jeu dans sa totalité, d’entrer dans les domaines où les joueurs ont tendance à négliger, en fait jeter un regard complet et complet sur le jeu et le tester de toutes les manières dont il a besoin.
Ne pas investir là-dedans, bien sûr, conduit à un cycle de souffrance. Les mises à jour sortent avec plus de bugs, moins de finition et moins de compréhension de ce que veulent les joueurs. Le blâme est imposé aux personnes qui effectuaient réellement les tests, puis vous revenez à la mise à jour suivante, et…
Ouais, vous voyez l’idée.
Les serveurs de test sont une bonne idée. Mais c’est une bonne idée qui ne fonctionne pas vraiment comme une batterie gratuite de testeurs QA professionnels et ne peut pas les remplacer. Et plus une entreprise essaie de remplacer les tests appropriés par les efforts des joueurs, plus les choses vont mal se passer dans l’ensemble.
Publicité
