Comment obtenez-vous des données utiles des testeurs de jeu? [fermé]

Il y a quelques types de commentaires que vous pouvez obtenir des testeurs de jeux, et je me demande comment recueillir au mieux les données pour chacun d'eux ...

1. Rapports de plantage. Lorsque mon jeu C ++ se bloque pendant que quelqu'un y joue, comment puis-je m'assurer au mieux que je le connais et encore mieux ... qu'est-ce qui l'a causé? Même obtenir quelque chose d'aussi simple que le numéro de fichier et de ligne qui a provoqué un crash serait incroyablement utile.

2. Commentaires sur la conception. Lorsqu'un testeur de jeu joue au jeu, comment savoir s'il s'amuse, pourquoi il s'amuse, pourquoi il ne s'amuse pas et que devrions-nous consacrer du temps à ajuster?

Je suppose que vous parlez de testeurs sur site et non de bêta-testeurs Internet.

Règle n ° 1: ne les aidez pas . La frustration devrait être la première chose à vérifier. La situation idéale serait un miroir à double sens avec votre équipe d'un côté et le testeur de jeu de l'autre avec une caméra vidéo sur le visage et une autre sur l'écran. De toute évidence, cela n'est pas possible pour la plupart des gens, alors faites de votre mieux. Le simple fait que vos concepteurs s'assoient et regardent où les gens sont coincés est une information très utile. Vous n'allez pas vous tenir au-dessus de leur épaule lorsqu'ils ramèneront le jeu à la maison, donc vous donner des conseils sur la façon de passer certaines sections ne vous donnera pas les informations dont vous avez besoin. Edit : une autre façon de le dire est la suivante: ne pensez pas qu'ils "jouent mal"

Règle n ° 2: ne leur donnez pas ce qu'ils veulent . Après une session de test, vous avez une sorte de questionnaire à remplir. Les suggestions spécifiques qu'ils ont ne sont généralement pas sages à prendre au pied de la lettre. Habituellement, il y a une cause profonde qui déclenche la plupart des réponses et ils ne savent tout simplement pas comment l'exprimer. Si vous pouvez comprendre cela, vous feriez mieux de le faire. Bien qu'à l'heure actuelle, j'ai du mal à trouver des exemples spécifiques.

Règle n ° 3: les données sont roi . Si vous le pouvez (et c'est vraiment un autre élément de la liste de souhaits, honnêtement), suivez tout ce que vous pouvez. Suivez où les joueurs meurent. Suivez où ils manquent de munitions d'un pistolet spécifique. Suivez les micros qui leur manquent. Suivez les mises à niveau qu'ils achètent. Suivez quels ennemis leur font du mal. Évidemment, ce sont des exemples spécifiques à FPS, mais je suis sûr qu'il existe des domaines spécifiques à chaque jeu que vous faites. Si tout le monde fait ou ne fait pas quelque chose, ce sont généralement des domaines sur lesquels vous devriez passer un peu plus de temps.

Fondamentalement, vous ne vous souciez pas de ce que pensent les joueurs . Vous vous souciez d'obtenir des chiffres bruts pour ce que font les joueurs . Vous avez besoin d'yeux vierges pour voir votre jeu et vous dire ce qui les rend frustrés et ce qu'ils sont amenés à faire.

Pour les plantages, étudiez les mini-décharges . Ils ne sont pas parfaits, mais sont un outil très utile pour déterminer où se trouvent les plantages.

Pensez également à un outil de rapport de bogue intégré. Quelque chose où l'utilisateur peut prendre une capture d'écran, ajouter une description et l'envoyer automatiquement à quelqu'un depuis le jeu. Idéalement avec un instantané du monde (c'est-à-dire une sauvegarde rapide ou une sorte de vidage de mémoire) si votre jeu le prend en charge.

Développer les données est un peu le sentiment du roi (+1 à Tetrad!):

Étudiez l' enregistrement et la lecture :

• Si votre jeu est déterministe et basé sur des trames, vous n'aurez peut-être qu'à stocker une graine aléatoire initiale et un tuple à (key/button state, joystick/mouse coords, frame #)chaque fois que l'état d'entrée change. La lecture est aussi simple que de rediriger votre entrée vers ce flux. (Nous l'avons fait pour de nombreux jeux de saut de plate-forme dans le passé.)
• Si votre jeu possède des API ou des systèmes de messages bien définis pour effectuer des actions (un jeu de stratégie au tour par tour, un jeu de cartes, un jeu de société, etc.), vous pourrez peut-être simplement récolter des appels ou des messages d'API à un certain point de pincement. . (Nous l'avons fait pour un jeu de cartes pour une plate-forme portable.)
• C'est plus difficile sur certains systèmes (les systèmes d'horodatage moins déterministes, filetés ou arbitraires peuvent être pénibles), mais cela vaut quand même la peine d'enregistrer les données; vous pouvez obtenir des résultats "assez proches" pour certaines utilisations.

Un système de "rejeu" basé sur ces méthodes présente de nombreux avantages:

• l'utiliser pour reproduire les plantages dans une version ou un environnement de débogage ou autrement instrumenté;
• charger des relectures sous une génération de profilage et obtenir des données de performances ou d'utilisation des ressources;
• connectez-le au jeu pour fournir une fonctionnalité de «relecture instantanée», peut-être avec un appareil photo ou un pas de temps différent;
• mettre en place un gameplay de démonstration en "mode attractif" si l'utilisateur reste sans rien faire sur un menu;
• mettez-le sur votre système de build comme un test de fumée: si je peux jouer à ce replay sans planter, c'est probablement une bonne build;
• regardez des exemples de personnes qui jouent pour voir ce qu'elles ont fait et ce qu'elles n'ont pas fait.

Câblez une entrée aléatoire plutôt qu'un flux enregistré, et vous avez un excellent test de singe que vous pouvez laisser tremper pendant la nuit ou chaque fois que vos machines de développement sont inactives.

Ensuite, faites un enregistrement d'événement . Pour un FPS hypothétique, commencez par quelque chose comme "le temps T: X a tué Y au point Z avec l'arme W": mettez-le dans un journal.

Une fois que vous avez collecté certaines données, découvrez comment automatiser la collecte . Il n'a pas besoin d'être élégant lors du développement:

• se connecter à un serveur SQL et insérer des lignes,
• déclencher et oublier les paquets UDP sur un simple serveur syslog-ish,
• envoyer le journal par e-mail la prochaine fois que le jeu démarre,
• il suffit d'envelopper l'exécutable dans un script shell ou un fichier batch qui renomme et copie un fichier .log sur un lecteur partagé commun,
• (plus tard, pour les versions de production) utilisez le rapport d'erreurs Windows ou un service similaire pour collecter les données de plantage ...

Cela n'a pas vraiment d'importance, tant que vous pouvez collecter des données.

Maintenant, étendez-le: collectez les vidages sur incident, les traces de pile et les enregistrements d'entrée ou d'événement. Ajoutez plus d'événements et plus de sources de données:

• échantillonnez la position ou la main du joueur toutes les 10 secondes, tracez-la sur une carte - "hé, personne n'utilise ce coin que j'ai passé une semaine à modéliser, le temps d'y mettre un bonus"
• getFreeMemoryBytes() toutes les demi-minutes
• getFPS() périodiquement
• prendre une photo ou une vidéo de ce que l'utilisateur fait via une webcam (idéal pour les tests d'utilisabilité automatisés - uniquement avec l'autorisation et la compréhension de l'utilisateur, bien sûr)
• récupérer les informations système (à nouveau, avec la permission de l'utilisateur)

Le truc "tracer sur une carte" peut devenir vraiment génial après un certain temps: imaginez une vue aérienne d'une carte RTS ou FPS. Mettez un curseur dessus, représentant le temps écoulé depuis le début du jeu. Sélectionnez un type d'événement ("obtenu de l'or", "tué quelqu'un", peu importe). Sélectionnez un ensemble de données: peut-être un jeu, peut-être 500 jeux au cours des derniers mois. Commencez à tirer le curseur vers la droite et regardez l'activité apparaître sur la carte.

Et si vous ne trouvez pas de bonnes bibliothèques pour vous aider avec ce genre de choses (il y en a pas mal ici et là, cependant!), Pensez à rouler la vôtre: c'est une bonne expérience d'apprentissage, et elle n'a pas besoin d'être particulièrement élégante Être utile.

Obtenez les données, vous saurez quoi en faire. =)

Bien sûr, cela dépend beaucoup ... a) du type de test que vous voulez faire, et b) du type de jeu que vous testez, et c) du type de testeurs et de l'infrastructure dont vous disposez ...

Cela diffère également beaucoup si vous testez a) la fonctionnalité, b) l'équilibre c) la conception du jeu

Mais en général, vous voudrez peut-être considérer ces aspects ...

* a) Choisir la bonne personne pour le travail Cela semble trop simple à mentionner, mais je l'ai vu plusieurs fois et je l'ai revu en direct. Comme toujours, il existe des différences significatives entre les personnes en ce qui concerne la qualité de leur travail. Certaines personnes désireuses ou désireuses de faire des tests peuvent ne pas jouer suffisamment pour trouver des bogues inhabituels (ou même simples). Certains ne sont pas bons pour décrire les bogues. Certains sont meilleurs pour tester les problèmes d'équilibrage, certains sont plus attentifs aux faiblesses visuelles, certains sont plus créatifs pour jouer au jeu de manière inhabituelle et découvrent des bugs rares / cachés, certains sont plus attentifs à la qualité technique ou visuelle, certains sont meilleurs dans la compréhension des aspects du mécanisme de jeu et peut même suggérer des changements significatifs (si vous voulez que vos testeurs le fassent;).

* b) Utiliser un logiciel Issue-Tracker / Bug-Tracker Ces outils peuvent non seulement vous aider à organiser vos problèmes, mais aussi à améliorer la qualité de la sortie de vos testeurs en leur donnant un cadre pour travailler et en tirant parti des commentaires qu'ils reçoivent. des développeurs sur leurs problèmes. Cela aide à améliorer la qualité de la sortie de vos testeurs beaucoup plus rapidement que si vous travaillez sans. (Il aide également beaucoup avec les testeurs à distance) Le logiciel typique utilisé par les studios de jeu est ie Mantis, JIRA, (et bien sûr beaucoup d'autres ..) Voir Wikipedia pour une liste générale et aussi ce post sur SO.

c) Ajouter des outils de test dans le jeu Les raccourcis pour tester des niveaux ou des sections spécifiques du jeu sont typiques. Affichage d'informations supplémentaires pendant le jeu aux testeurs afin qu'ils puissent les ajouter aux rapports de bogues. Cela pourrait être la position dans un niveau, le nombre d'objets actifs dans une scène, la quantité de texture-ram ou de palettes actuellement utilisées, tout ce qui est utile aux développeurs.

d) Combinez des testeurs expérimentés avec du sang frais. C'est toujours une bonne chose d'avoir des testeurs qui sont très expérimentés avec votre jeu et qui ont appris quels sont les problèmes typiques et comment les (re) tester. En même temps, vous voulez de nouveaux joueurs "vierges" de temps en temps, en particulier pour l'équilibrage.

e) Avoir un gestionnaire de test Quelqu'un qui coordonne le processus et l'adapte au jeu en cours, aux priorités actuelles et aux testeurs disponibles et à l'environnement de test.

f) Avoir un document de plan de test Cela vaudrait un poste supplémentaire.

Comme Tetrad l'a mentionné, obtenez autant de données objectives que possible. Mettre des crochets pour stocker certains événements et les vider tous dans un .csv n'est pas très difficile. Et une fois que vous l'avez dans Excel, vous pouvez étudier, représenter graphiquement et tracer jusqu'à ce que les vaches rentrent à la maison.

Vous avez également des questions spécifiques auxquelles vous cherchez à répondre. Les scientifiques ne se contentent pas de s'asseoir, de lancer des expériences et de «faire de la science». Ils ont des questions spécifiques et mesurables sur lesquelles ils veulent des données. Vous tirerez souvent le meilleur parti des tests de jeu si vous adoptez la même approche. Essayer de déterminer si votre jeu est "bon" est très difficile à quantifier. Mais déterminer si la mission de didacticiel simple ne prend que les 5 minutes que vous attendez ou si les testeurs ont du mal à résoudre un certain casse-tête peuvent être évalués.

Parfois, le moyen le plus efficace de tester est itérativement en courtes rafales. Demandez à quelques testeurs de passer une heure environ le matin, apportez des modifications aux problèmes qu'ils identifient et revenez avec de nouveaux testeurs le lendemain matin. De toute évidence, vous devez examiner une fonctionnalité suffisamment petite pour être améliorée en un après-midi. Mais pour un problème particulièrement tenace, cette méthode peut être très efficace.

Entièrement d'accord avec la règle n ° 1 de Tetrad. Ne les aide pas. Je dirais qu'une mise en garde consiste à leur expliquer que vous ne les aiderez pas, et s'ils ont besoin d'aide, veuillez demander. De cette façon, le joueur ne finit pas par être frustré.

Le questionnaire doit poser des questions ouvertes, au lieu de celles qui sont simples oui / non, selon l'âge et le nombre de testeurs, il peut s'agir de formulaires à remplir, ou vous pouvez poser les questions. Il est également important de poser des questions sur leur histoire et leur familiarité avec le genre de jeu que vous leur faites tester; cela ajoutera du contexte à leurs réponses spécifiques sur votre jeu.

Heureusement, lorsque mon jeu se bloque, cela me donne un vidage d'informations concernant l'erreur, donc je peux prendre une photo de cela et noter ce que le joueur faisait. Normalement, je teste des groupes d'âge plus jeunes, donc quand nous obtenons un crash, je dois me rappeler de leur expliquer qu'ils font un excellent travail - ils peuvent se fâcher après avoir cassé le jeu. Les testeurs de jeu se sont révélés très efficaces pour trouver des bugs obscurs que l'équipe de développeurs ne rencontrerait jamais en jouant au jeu de la "bonne" manière.

Il est possible d'écrire du code qui détecte les plantages et enregistre la pile d'appels. Cela peut aider beaucoup avec les rapports de bogues. La génération d'un fichier journal utile aide également. Vous pouvez inviter l'utilisateur à envoyer ces fichiers la prochaine fois qu'il joue, ou disposer d'un outil autonome qui s'exécute après la fermeture du jeu ou se bloque si vous le souhaitez.

Pour les rapports de plantage, vous devriez vous fier au personnel QA rémunéré, pas aux testeurs de jeu. L'AQ est quelqu'un que vous engagez spécifiquement pour sa capacité à trouver des bogues et à les signaler de manière significative, et un bon testeur vaut son pesant d'or (et ne coûte que le dixième de son poids en or, par rapport aux programmeurs!).

Si vous vous inquiétez de "oh, que se passe-t-il s'ils découvrent accidentellement un plantage, nous ne voudrions pas le manquer simplement parce qu'ils ne testent pas cela" ... c'est à cela que sert la journalisation. Un système d'enregistrement suffisamment bon devrait enregistrer suffisamment d'éléments de jeu pour pouvoir reproduire exactement un crash.

Pour les commentaires sur la conception, rien ne peut remplacer le fait que vos concepteurs de jeux les regardent jouer (ou utiliser un magnétoscope si vous le devez, etc.). Ne vous fiez pas à la mémoire ou à l'opinion du testeur, tous deux notoirement pauvres. Mais si vous les regardez jouer en temps réel, il est évident que rien qu'en regardant leur visage et leur posture, qu'ils soient engagés, ennuyés ou frustrés.