L'industrie des jeux utilise-t-elle des tests automatisés pour les parties visuelles des jeux / rendu? Comment?

Certaines parties d'un jeu sont faciles à tester de manière automatisée (logique, mathématiques, gestion des entrées); mais il y a aussi beaucoup de choses purement visuelles et difficiles à tester.

Je serais surpris si l'industrie des jeux laissait tout cela à des tests manuels; il y a suffisamment d'argent pour que je suppose que des efforts ont été déployés pour pouvoir tester au moins certains aspects visuels des jeux.

Est-ce vrai? Si oui, quelles sont les manières possibles de tester le rendu des jeux? Capture de sortie et comparaison d'images (cela peut-il être fiable?)? Intercepter les données de la carte graphique à un bas niveau? Capturer des informations de sommet (etc.) sur son chemin vers la carte graphique? Il semble qu'il y ait beaucoup de possibilités; mais je ne trouve aucune information à ce sujet :(

Remarque: Cette question a été marquée comme une dupe de celle-ci , mais je ne pose pas de question sur des technologies / cadres / outils spécifiques sur la façon de le faire, mais plus largement sur les idées autour de cette pratique et sur ce que fait l'industrie du jeu (si ils le font du tout).

unit-testing testing game-development

— Danny Tuppeny
source

Je dirais qu'ils utilisent probablement une bibliothèque graphique bien testée (tierce ou développée en interne). Quand ils arrivent à concevoir un niveau de jeu, ils ne vérifient pas que chaque objet est exactement aux coordonnées X, Y, Z, ou si la perspective est correcte, mais des choses plus simples comme s'assurer que les objets sont là et non bloqués par les murs, etc. Et si la bibliothèque graphique est développée en interne, les tests sont automatisés et plus basiques.

— SJuan76

@ SJuan76 Je suppose que si vous construisez au-dessus d'un moteur, la question s'applique aux tests du moteur

— Danny Tuppeny

Cette question n'a-t-elle pas une portée un peu plus large que celle dont elle a été marquée comme un double? L'OP n'a pas mentionné C ++ ou OpenGL. L'industrie du jeu est plus grande que cela.

— toniedzwiedz

Il est probablement plus facile de prouver formellement que le code est correct étant donné que les API graphiques sont exemptes de bogues que de tester que le matériel fait son travail. Étant donné que les pilotes AMD et NVidia sont propriétaires, j'imagine que le protocole impliqué dans la communication avec la carte graphique est 1) propriétaire, 2) sujet à changement et 3) varie d'une carte à l'autre. De plus, même si les données envoyées à la carte graphique sont correctes, comment savez-vous que la carte graphique n'a pas de défaut matériel?

— Doval

J'ai essayé de rouvrir cela car la cible dupe était plus spécifiquement sur les stratégies de test automatisé des graphiques OpenGL. Ce n'est pas ma spécialité, mais je fais confiance aux commentaires d'autres personnes qui connaissent très bien l'industrie du jeu, je veux donc lui donner une autre chance. Pour une référence à la question similaire, voir ici: programmers.stackexchange.com/questions/150688/…

— maple_shaft

Toute entreprise fera de différentes manières, même différents jeux seront testés différemment.

Peut-être que le manque d'informations sur les graphiques est dû au fait que le rendu est en effet assez "répétitif" (je ne peux pas penser à un meilleur mot, désolé) et dans une scène complexe typique, il y aura suffisamment de combinaisons primitives pour que la plupart des personnes puissent généralement voir facilement la plupart des problèmes ( à l'exception des shaders moins utilisés, mais un niveau / démo spécial stress-shader peut être utilisé). N'oubliez pas que les humains étaient des chasseurs depuis des milliers d'années :) alors nous sommes probablement conçus pour détecter les problèmes.
De plus, la liberté de mouvement présente dans la plupart des jeux et la randomisation d'autres éléments sur un jeu typique qui le rend plus "réaliste" sont généralement un cauchemar pour appliquer de purs tests automatisés: en fait, un testeur humain trouvera plus rapidement et plus erreurs que tout test automatisé. Vous pouvez coder une logique pour enregistrer les temps, les statistiques et les positions / angles / autres variables à chaque fois qu'un testeur joue ... donc même sur des tests non automatisés, vous aurez des commentaires comme des tests automatisés. Il est généralement utile de pouvoir lire une session enregistrée de n'importe quel bêta-testeur (et c'est généralement une bonne fonctionnalité pour le jeu final également).
À propos du rendu des statistiques, par exemple, vous pouvez obtenir: les statistiques du nombre d'appels d'appel pour chacun des shaders (car vous effectuerez les appels, il suffit de maintenir certains compteurs), les nombres de téléchargement (les mêmes, vous contrôlerez quand les tampons gpu sont mis à jour), les timings (non seulement les fps, aussi les intervalles entre chaque appel), etc. (par exemple, vous pouvez obtenir des taux de remplissage et autres en utilisant des requêtes d'occlusion).
Enfin, une autre raison d'utiliser les bêta-testeurs est que les différentes cartes graphiques auront probablement des comportements différents ... vous devrez peut-être avoir une batterie de machines de test o_O. Les bêta-testeurs humains adorés adouciront tout ce gâchis.

J'espère que ça aide!

Disclaimmer: Je ne suis pas bêta testeur, je suis développeur XDDD.

— user1039663
source

Je suis entièrement d'accord avec le fait que les humains sont conçus pour voir des motifs, des défauts, ... Nous sommes en effet des êtres visuels.

— Trilarion