Get best of the week

Test du moteur de jeu Amazon Lumberyard. Approches et outils

Amazone Jeux. Cela semble inhabituel? Comment tester le produit pour les développeurs et les joueurs? Dans le cadre des tests de coupure du moteur de jeu Amazon Lumberyard, des approches à la fois dans les tests manuels et l'automatisation, ainsi que les outils utilisés sur le projet.



Lumberyard est un moteur de jeu multiplateforme où vous pouvez créer des jeux gratuitement pour les plates-formes les plus modernes: PC, Mac, iOS / Android, toutes les consoles, y compris les lunettes de réalité virtuelle. Il est également assez profondément intégré aux services Web d'Amazon et au service de diffusion de jeux de Twitch.

Sous la coupe - vidéo et transcription du rapport d'Artem Nesiolovsky de la conférence de Heisenbug .




À propos du conférencier: diplômé de l'Institut de génie physique de Moscou, Faculté de cybernétique, plus de 8 ans en développement et tests. Il a travaillé à la fois sur des projets de bureau, tels que GeForce Experience, le MMORPG en ligne Lineage II, et sur mobile - le jeu Cut the Rope, ainsi que sur le projet Web Yandex.Images. Il est actuellement ingénieur en automatisation chez Amazon sur le projet Amazon Lumberyard.

Structure de poste


  • Moteur de jeu: fonctionnalités, ainsi que les différences entre tester le moteur et tester les jeux.
  • Test manuel: comment nous avons essayé de découvrir la couverture des fonctionnalités du projet avec des tests fonctionnels.
  • Automatisation: erreurs et bosses que nous avons remplies et traitées par la suite.
  • Des outils avec lesquels nous automatisons notre moteur.
  • Bugs intéressants de notre projet que vous avez probablement rencontrés lorsque vous avez joué à des jeux vous-même.


Nouvelle narration au nom de l'orateur.



Pourquoi Amazon fait-il des jeux? En 2014, Amazon, comme de nombreux géants de la technologie, note que les jeux deviennent la deuxième forme de divertissement la plus populaire pour l'humanité. Le premier, curieusement, est la télévision, ou plutôt tout ce qui concerne le streaming vidéo (YouTube, Netflix et tout le reste). Les développeurs de jeux commencent également à utiliser plus activement les services AWS pour leurs jeux en ligne.

Amazon décide de construire un écosystème sur trois piliers: ouvrir son studio de jeu pour créer des jeux que les gens pourront ensuite diffuser et regarder sur Twitch. Ces jeux montreront également quelles idées de gameplay intéressantes peuvent être mises en œuvre à l'aide d'AWS Cloud.

Comment tout cela a-t-il commencé?


En 2004, la société allemande Crytek a sorti un jeu appelé "FarCry". Après un certain temps, Crytek commence à licencier son moteur, sur lequel le jeu a été construit, afin que des sociétés tierces puissent prendre le moteur fini et commencer à créer un jeu, un gameplay, le remplir de contenu sans un gros investissement technologique. Quand Amazon a commencé à jouer à des jeux, il a également ouvert immédiatement plusieurs studios et a commencé à développer plusieurs jeux.

Pour que chaque studio n'invente pas de vélo - son propre moteur de rendu, son système d'animation, sa physique, etc., Amazon concède une licence à CryEngine version 3 et lance le développement de plusieurs jeux à la fois. Le Grand Tour est déjà sorti sur Xbox et PlayStation. Deux autres sont en cours de développement: le MMORPG "New World" et le jeu de tir en ligne "Crucible". Une fois le développement de ces jeux commencé, Amazon commence à fournir gratuitement le moteur sur lequel ces jeux sont développés. Parce qu'il est hautement intégré aux services cloud d'Amazon, vous pouvez attirer plus de personnes à utiliser AWS.



Un moteur de jeu est un ensemble d'API, un moteur de jeu pour construire un futur jeu. Pour que les développeurs n'aient pas besoin d'écrire leurs propres systèmes de jeu, vous pouvez simplement prendre un ensemble d'API, c'est-à-dire moteur, et commencez à écrire votre propre logique de jeu, ajoutez-y du contenu et engagez-vous dans la créativité, au lieu de développer la technologie à partir de zéro. De plus, certains moteurs ont un éditeur. Il s'agit d'un programme de bureau dans lequel vous pouvez créer des niveaux, c'est-à-dire ouvrir votre niveau et y ajouter du contenu et une logique de jeu.

Au lieu de parler longtemps, il est parfois plus facile de montrer une vidéo:

Lien vers la vidéo 8: 33-9: 53

Voici notre éditeur et son interface. Un jeu est lancé à l'intérieur, que nous fournissons avec le moteur. "Starter Game" existe pour que les gens puissent se connecter, jouer, changer quelque chose et comprendre comment cela fonctionne.

En général, les jeux 3D peuvent être imaginés comme un ensemble d'objets tridimensionnels qui se déplacent dans un monde tridimensionnel et interagissent d'une manière ou d'une autre. Dans cette vidéo, vous pouvez voir:

  • géométrie statique avec textures: terre, pierres, herbe, arbres;
  • géométrie dynamique - le personnage est animé, réagit aux actions du joueur;
  • interface utilisateur: vues des tâches dans le coin supérieur gauche.

Le joueur peut rencontrer des personnages hostiles, la logique du jeu apparaîtra, il sera possible de tirer - les robots tireront en réponse. À propos de la physique: le personnage commencera à tirer sur des tonneaux, il se déplacera des collisions avec les tirs et d'interagir avec le personnage. Dans l'éditeur, vous pouvez à tout moment quitter le mode de jeu et revenir au mode d'édition, dans lequel vous pouvez immédiatement changer les propriétés des objets, les déplacer, et cela apparaîtra immédiatement sur le gameplay. Imaginez un nombre approximatif d'endroits où quelque chose pourrait mal tourner, tomber en panne et cesser de fonctionner correctement?

Comment tester le moteur?


Le test du moteur est basé sur trois points principaux. La première consiste à tester l'éditeur et les outils: le bon fonctionnement, les outils doivent s'ouvrir, rien à planter, tout doit s'afficher correctement, les scripts utilisateur doivent être exécutés sans erreurs, le processus de création d'un jeu sans bugs d'accompagnement. Seuls les créateurs de jeux utiliseront l'éditeur. Le second teste le moteur lui-même ou l'API du moteur. Le moteur de jeu, à son tour, est la partie du code qui fonctionnera, y compris sur les ordinateurs des joueurs. Cette partie du projet est testée à travers la création préalable de niveaux et de jeux. Par la suite, les niveaux créés peuvent être testés sur chaque nouvelle version du moteur pour s'assurer que tous les éléments de jeu utilisés à l'un ou l'autre niveau fonctionnent comme ils le devraient.Et le troisième composant est le test de l'infrastructure et de la compatibilité: le moteur peut être configuré et construit avec différents paramètres, le jeu peut être déployé sur différents appareils, et il ressemblera et fonctionnera presque partout de la même manière.
Caractéristiques du projet

La première caractéristique - nous prenons en charge la plupart des plates-formes de jeux existantes. Malgré le fait que l'éditeur lui-même ne fonctionne que sur PC, runtime, c'est-à-dire Le jeu peut être construit sur Mac, smartphones, consoles et même des lunettes de réalité virtuelle.

La deuxième fonctionnalité - nos utilisateurs - ce sont deux types de personnes avec des demandes complètement différentes. D'une part, ce sont des développeurs, programmeurs, artistes et designers qui travailleront à la création du jeu. Et d'autre part, ce sont des joueurs, sur les machines dont le jeu fonctionnera ensuite. Les exigences pour ces deux groupes sont complètement différentes.

La troisième caractéristique - dans de tels programmes qui vous permettent de créer quelque chose de nouveau, la gamme la plus large possible de produits possibles de cette application est impliquée à l'avance. Sur notre moteur, vous pouvez créer absolument n'importe quel jeu, à partir de quelque chose de simple, comme Tetris, et se terminant par un projet en ligne complexe, qui est joué par des milliers de personnes en même temps.

Ces trois fonctionnalités affectent considérablement le nombre de scripts personnalisés, dont chacun doit être testé.



Regardez cette capture d'écran et imaginez combien de cas de test vous pourriez écrire juste pour cette partie de la fonctionnalité? Au total, nous avons plus de 11 000 cas de test sur le projet et cette base de données augmente d'environ 3 à 4 000 cas de test chaque année.

Lien vers la vidéo 13: 20-13: 54

Nous trouvons la plupart des bogues lors de l'interaction de plusieurs composants entre eux. Dans cette vidéo, la neige à l'état normal est affichée sur le cube comme il se doit, mais dès que le personnage commence à interagir avec lui, la neige commence à disparaître. La plupart des bogues que nous trouvons se trouvent dans des endroits où plusieurs composants se rejoignent.

Lien vers la vidéo 14: 08-14: 41

Cependant, les bogues ne se produisent pas toujours lorsqu'il n'y a que deux conditions. Il arrive souvent que des bogues apparaissent lorsque plusieurs composants convergent en même temps. Dans ce cas, nous considérons un bug dans lequel, dans une situation normale, le personnage se tient simplement au sol. Cela vaut la peine d'ajouter un autre degré de liberté - pour élever le personnage au-dessus du sol: quand il tombe, l'animation commence à jouer et la caméra s'approche / s'éloigne - la texture commence à disparaître. Ici, trois composants interagissent à la fois: la hauteur, l'animation des personnages et la distance de la caméra. Il est impossible de réfléchir à l'avance à toutes ces options, et nous ne trouvons souvent de tels bogues que lors de tests ad hoc.

Lien vers la vidéo 15: 02-15: 49

Il y a une autre caractéristique - nous avons de nombreux systèmes non déterministes. Ce sont des systèmes dans lesquels, avec la même entrée, le résultat final peut différer. Un exemple simple est qu'il existe des variables aléatoires dans le système. Dans notre cas, ce sont des systèmes de physique dans lesquels il existe de nombreux calculs avec des nombres à virgule flottante. Les opérations en virgule flottante sur différents processeurs ou compilateurs peuvent être effectuées un peu différemment. Pour cette raison, la fonctionnalité résultante sera toujours légèrement différente. En conséquence, de tels systèmes sont assez difficiles à automatiser, car il est difficile d'expliquer à la machine dans quel cas il s'agit d'un bug, et dans ce cas ce sont des différences acceptables.

Lien vers la vidéo 16: 03-17: 14

Il existe de nombreuses interactions non triviales dans le moteur et dans l'éditeur lui-même. Les utilisateurs interagissent souvent dans un espace tridimensionnel à l'aide de la souris et du clavier. Cette vidéo comportera une fonctionnalité appelée objet simulé. Les choses habillées sur le personnage doivent se déplacer selon les lois de la physique lors du déplacement du personnage sur lequel ces articles sont portés. Par exemple, des vêtements ou une mallette. Comme un tel élément dans la vidéo - la main du personnage. Lorsque le personnage bouge, la main commence également à répondre. Souvent, pour tester une telle fonctionnalité, vous devez effectuer des actions non triviales: changer quelque chose dans l'interface utilisateur, déplacer des objets dans un espace tridimensionnel, faire glisser-déposer, regarder également les graphiques d'animation qui se trouvent ci-dessous et tout faire en temps réel. Cette fonctionnalité affecte la complexité de l'automatisation.

Comment déterminer la couverture?


À un moment donné, nous avons réalisé que nous avions écrit de nombreux cas de test, mais il était difficile de déterminer quelle couverture nous avions. Nous avons trouvé la plupart des bogues critiques non pas lors de notre test de régression complet, mais lors de tests ad hoc, qui ont été effectués à la fin du cycle de publication. Nous avons commencé à penser: nous avons un moteur avec beaucoup de fonctionnalités, nous avons un référentiel dans lequel 12 000 cas - comment comprendre dans quels endroits il y a suffisamment de couverture et dans lequel cela vaudrait la peine d'ajouter des cas de test?

Nous nous sommes tournés vers la théorie des tests, avons commencé à lire comment les gens définissent la couverture des tests. Une façon consiste à déterminer via le code source. Dans notre cas, c'est difficile à faire. Nous avons plusieurs millions de lignes de code et il a été impossible de terminer cette vérification en peu de temps. La deuxième méthode consiste à évaluer la couverture par une évaluation des besoins. Dans les processus agiles, les exigences sont souvent stockées uniquement dans la tête des personnes, et non dans la documentation, de sorte que les exigences pour effectuer une évaluation de la couverture n'étaient pas non plus réalistes. En conséquence, nous nous sommes tournés vers la seule voie possible pour nous - la définition de la couverture par l'écriture d'un modèle.



Nous avons choisi un modèle appelé ACC - Attribut, Component, Capability. ACC est l'un des modèles les plus simples, ce qui est assez courant dans Amazon pour les logiciels de modélisation. Le modèle est construit sur trois piliers principaux. Premièrement, ce sont des composants, les noms sont les principales parties actives du système. Pour nous, c'est la vue, la texture, l'essence du jeu. Voici les capacités - verbes - que peuvent faire ces composants. Par exemple, ils peuvent s'afficher à l'écran, calculer quelque chose, déplacer quelque chose, etc. Et la troisième partie est des attributs - adjectifs ou adverbes liés à la fois aux composants et à leurs capacités. Les attributs décrivent les paramètres des capacités: rapide, sécurité, évolutif, sécurisé, etc. Tout cela se résume à trois questions: qui? que fait-il? Et comment?

Nous analyserons ce modèle avec un petit exemple. Voici une démonstration d'une petite partie des fonctionnalités:

Lien vers la vidéo 19: 59-21: 02

La fenêtre d'affichage est la partie de l'éditeur où le niveau est visible. La vidéo a montré qu'il est possible de faire pivoter la caméra, de se déplacer dans le niveau, il est possible d'ajouter un personnage du conducteur local d'objets de jeu. Vous pouvez déplacer un personnage ou créer une nouvelle entité de jeu en cliquant avec le bouton droit, vous pouvez sélectionner toutes les entités actuelles au niveau et les déplacer toutes ensemble. Vous pouvez également ajouter un autre élément géométrique et (comme dans tous les éditeurs tridimensionnels) modifier non seulement sa position dans l'espace, mais également changer son angle et le redimensionner. Une fenêtre appelée «Viewport» a différents modes de rendu. Par exemple, les ombres sont désactivées ou certains effets graphiques du post-traitement sont désactivés. Vous pouvez entrer dans le mode de jeu pour tester immédiatement les modifications qui viennent d'être apportées.



Regardons le modèle ACC lui-même. Nous avons rapidement réalisé que ces modèles sont très pratiques à utiliser avec Mindmaps, puis nous les traduisons soit en tablettes, soit directement dans la structure de TestRail ou dans tout autre référentiel pour les cas de test. Le composant principal lui-même est visible dans le diagramme au centre - Fenêtre - et plus au-dessus de la branche rouge se trouve la fonction Fenêtre qui vous permet de vous déplacer dans le niveau: vous pouvez faire pivoter la caméra, vous pouvez voler en utilisant les boutons "W", "A", "S", "D".

Sa deuxième opportunité (branche orange) est de créer des entités de jeu via Viewport ou via glisser-déposer depuis l'explorateur de jeux.

Et les entités du troisième jeu peuvent être manipulées: elles peuvent être distinguées, leur emplacement changé, tourné, etc. La branche verte à gauche est la configuration de la fenêtre lorsque vous changez de mode de rendu. Un attribut est mis en surbrillance dans la branche bleue, ce qui indique que la fenêtre d'affichage doit également répondre à certains paramètres de performances. Si cela ralentit, les développeurs auront du mal à faire quoi que ce soit.

L'ensemble de l'arborescence est ensuite transféré vers TestRail. Lorsque nous avons transféré les cas de test de notre ancien système vers la nouvelle structure, il est immédiatement devenu clair où les cas de test manquaient - à certains endroits, des dossiers vides sont apparus.



Lien vers la vidéo 23: 01-24: 10

Ces structures se développent assez rapidement. Viewport fait référence à l'éditeur, qui n'est qu'une partie du moteur. Deux parties principales: l'éditeur lui-même et le moteur de jeu lui-même. Sur la droite de l'image ci-dessus, vous pouvez voir plusieurs composants qui ne sont pas liés à l'arborescence. Par exemple, un système de rendu ou de script, les animations sont distinctes, car elles se rapportent immédiatement à la fois à l'éditeur et au moteur. Autrement dit, le système de rendu fonctionnera au moment de l'exécution sur les appareils finaux, mais dans l'éditeur lui-même, il sera possible de modifier certains paramètres: heure du jour et de la nuit, matériaux d'édition, système de particules.

Résultats et conclusions


La modélisation ACC a permis de mettre en évidence les domaines dans lesquels les patients couverts par le test. Comblant les lacunes dans la couverture, le nombre de bogues trouvés après notre passage complet de régression a été réduit d'environ 70%. Les modèles ACC faciles à construire se sont également révélés être une bonne source de documentation. Les nouvelles personnes qui sont venues au projet les ont étudiées et ont rapidement pu se faire une idée du moteur. La création / mise à jour des modèles ACC fait partie intégrante de notre processus de développement de nouvelles fonctionnalités.



Nous avons commencé à automatiser le moteur grâce à l'automatisation de l'interface utilisateur. L'interface de l'éditeur est écrite dans la bibliothèque QT. Il s'agit d'une bibliothèque pour écrire l'interface utilisateur multiplateforme pour les applications de bureau, qui peut fonctionner à la fois sur Mac et Windows. Nous avons utilisé un outil appelé Squish de Froglogic, qui fonctionne sur un système similaire avec WebDriver, adapté à l'environnement de bureau. Dans cet outil, une approche similaire à Page Object (du monde de WebDriver) est utilisée, elle est appelée différemment - Composite Elements Architecture. Les sélecteurs sont faits sur les composants principaux (comme une «fenêtre» ou un «bouton») et les fonctions pouvant être exécutées avec ces éléments sont enregistrées. Par exemple, «clic droit», «clic gauche», «enregistrer», «fermer», «quitter». Ensuite, ces éléments sont combinés en une seule structure,vous pouvez y accéder dans votre script, les utiliser, prendre une capture d'écran et comparer.

Problèmes et solutions


Le premier problème est la stabilité. Nous avons écrit des tests qui testent la logique métier via l'interface utilisateur - quel est le problème? Lorsque la logique métier ne change pas, mais que l'interface change - les tests tombent, vous devez télécharger de nouvelles captures d'écran.

Le problème suivant est le manque de fonctionnalités. De nombreux cas d'utilisation ne sont pas simplement en appuyant sur un bouton, mais en interaction avec le monde tridimensionnel. Cette bibliothèque ne le permettait pas, de nouvelles solutions étaient nécessaires.

Le troisième problème est la vitesse. Pour tout test d'interface utilisateur, vous devez rendre entièrement le moteur entier. Cela prend du temps, les machines pour ces tests doivent être suffisamment puissantes.



La solution est venue sous la forme d'une bibliothèque Shiboken. Cette bibliothèque fournit des classeurs à partir du code C ++ en Python, ce qui permet d'appeler directement les fonctions fournies par l'éditeur ou le moteur sans rendre l'éditeur d'interface utilisateur. Un analogue du monde du Web - l'automatisation sans tête (quelque chose de similaire à PhantomJS) - vous pouvez automatiser une application Web sans lancer de navigateur. Dans ce cas, un système similaire, uniquement pour une application de bureau écrite en C ++.

Après avoir commencé à investir dans ce cadre, nous avons réalisé qu'il peut être utilisé non seulement pour automatiser les tests, mais aussi pour automatiser tous les processus à l'intérieur du moteur. Par exemple, un concepteur doit mettre 100 sources lumineuses dans une rangée (par exemple, il fait une route et vous devez mettre des lumières). Au lieu de représenter manuellement toutes ces sources de lumière, vous écrivez simplement un script qui crée une entité de jeu, y ajoute une source de lumière ponctuelle et prescrit que tous les 10 mètres vous devez copier la lumière ponctuelle précédemment créée. Un bonus pour nos utilisateurs sous la forme d'un outil d'automatisation des tâches de routine.



La deuxième partie de la solution au problème. Nous avons rapidement réalisé que pour automatiser diverses parties de notre moteur - par exemple, les éléments graphiques et réseau - nous avions besoin de cadres complètement différents. Il est impossible de créer un cadre unique et monstrueux qui aidera à tout automatiser à la fois. Par conséquent, nous avons commencé à développer un framework appelé Lumberyard Test Tools (pour faire court - LyTestTools). Il est basé sur Pytest (beaucoup de choses sont écrites dans le moteur en Python). Nous avons décidé d'utiliser l'architecture dite Plug-and-play - le groupe central d'ingénieurs en automatisation écrit la partie principale du cadre, qui peut télécharger, configurer le moteur, le déployer sur diverses plates-formes, exécuter des tests et collecter des journaux, télécharger des rapports dans notre base de données ou S3 et dessiner graphiques dans Quicksight. Plug-and-play est réalisé grâce à Test Helper,qui sera écrit par des équipes dans le domaine qui développe des fonctionnalités.

Autrement dit, l'équipe de développement graphique testera avec des captures d'écran et l'équipe d'interaction réseau vérifiera les paquets transférés. En même temps, ils seront tous connectés à notre cadre commun (au fur et à mesure que les deux équipes développent et testent des modules d'un seul moteur) afin qu'ils aient tous les mêmes interfaces pour exécuter des tests et générer des rapports, afin que tout fonctionne plus ou moins standardement et correctement avec notre CI / Cd.

Interaction avec Lumberyard


Quels peuvent être les modes d'interaction / d'automatisation d'une application de bureau? Premier type d'interaction entre le framework et le moteur - directement à partir de Python, le processus est lancé à l'aide de la fonction Sous-processus, si l'application implique un lancement via la ligne de commande. Vous pouvez lire l'entrée / sortie à partir de la sortie d'entrée / sortie standard et ainsi faire des affirmations. Le type suivant - cette interaction à travers l'analyse des journaux - vous pouvez lire et analyser les journaux laissés par l'application. Le troisième passe par le réseau. Dans les lanceurs de jeux, il existe un module appelé console à distance. Lorsqu'un certain port est ouvert sur l'appareil, notre framework peut envoyer des paquets / commandes spécifiques. Par exemple, prenez une capture d'écran ou ouvrez un niveau spécifique. Une autre méthode est l'interaction par la comparaison d'informations visuelles, c'est-à-dire captures d'écran.La méthode d'appel des fonctionnalités de l'application directement via l'API du produit a également été mentionnée précédemment (dans notre cas, il s'agit d'un appel via des liaisons Python à la fonctionnalité de l'éditeur / moteur C ++).

Passons à des exemples d'utilisation de notre framework pour automatiser le moteur.

Jetez un œil à cette capture d'écran.



Les détails sur ce site sont assez élevés - une grande quantité de végétation. Dans les jeux modernes, les niveaux peuvent prendre jusqu'à plusieurs dizaines et centaines de kilomètres de jeu. Naturellement, chacun de ces buissons de jeu n'est pas déposé manuellement, sinon les développeurs deviendraient tout simplement fous. Pour eux, notre moteur dispose d'outils spéciaux.

L'un d'eux s'appelle l'outil de végétation. Petite démo:

Lien vers la vidéo 32: 18-34: 06

Nous voyons le début standard du niveau. Il y a de la terrane et on peut très vite faire un relief: en arrière plan faire des montagnes, dans la partie centrale mettre également en valeur une petite colline. Vous pouvez peindre le sol lui-même vert avec une texture d'herbe. Le processus d'ajout de végétation, dans ce cas, des arbres, est également démontré. La géométrie - arbres, est ajoutée à l'outil - un sous-ensemble d'entre eux est mis en évidence, et tout dessin nécessaire peut être dessiné avec ces arbres. Ceci est un exemple assez simple, cet outil a de nombreux paramètres personnalisables. Par exemple, vous pouvez sélectionner non pas un arbre, mais plusieurs à la fois et définir un paramètre pour eux, vous tenir à une certaine distance les uns des autres ou définir des paramètres aléatoires pour la taille ou la rotation de ces arbres. Vous pouvez ajouter un personnage de jeu et exécuter immédiatement le niveau, tester,qu'est-ce que vous venez de cultiver dans votre propre jardin de jeux.

Voyons maintenant comment nous avons automatisé cette fonctionnalité avec notre framework en utilisant quelques tests comme exemple.

Lien vers la vidéo 34: 20-34: 58

Il y a une terrane standard et beaucoup de même type d'herbe y pousse. Ce type de rendu est très gourmand en processeur. S'il y a beaucoup de tels éléments, vous pouvez faire un test de charge. Un script de jeu a été ajouté ici, qui lors du démarrage du mode de jeu fera simplement un vol à travers ce niveau. La tâche consiste à tester cette fonctionnalité et à vérifier que le lanceur de jeu est stable et ne se bloquera pas.



Voici un exemple de la façon dont l'équipe qui a développé la fonctionnalité pour la croissance de la végétation a écrit Test Helper, qui vous permet de travailler avec ces fonctionnalités. Ceci est un exemple d'utilisation de notre framework. La classe du lanceur est surlignée en vert. Lorsque le test démarre, le lanceur est déployé, commence avec des paramètres de délai d'expiration et nous faisons une affirmation pour vérifier que le lanceur ne se bloque pas après un certain temps. Ensuite, nous l'éteignons.



Le code de paramétrage ci-dessus montre que nous pouvons réutiliser le même code sur différentes plateformes. De plus, nous pouvons réutiliser le même code à différents niveaux ou projets. Par exemple, les plateformes sont surlignées en rouge: dans un cas, c'est Windows, dans un autre cas, c'est Mac; le projet est surligné en jaune; le niveau du nom est surligné en jaune clair.

Lien vers la vidéo 36: 07-36: 47

Maintenant, à propos du test - dans ce cas, exécutez-le via la ligne de commande. Un programme s'ouvre appelé Asset Processor, l'une des principales parties du moteur. Ce programme traite les ressources source (par exemple, les modèles et les textures créés par des artistes) dans des formats compréhensibles pour le moteur et écrit tout dans la base de données (SQLite) afin que le moteur puisse naviguer rapidement et charger les données nécessaires pendant le jeu. Ensuite, le lanceur démarre, le mode de jeu démarre, la caméra vole au-dessus du niveau pendant plusieurs secondes et le test se termine. Nous constatons qu'un test a réussi et deux tests ont été ignorés. Cela est dû au fait que lors de l'enregistrement de la vidéo, le test a été poursuivi sur Windows, et dans le paramétrage, il y a deux autres plates-formes qui ont été respectivement ignorées lors de ce lancement.



Il existe une option plus difficile. Nous ne nous contentons pas de lancer le lanceur avec le niveau fini, mais le script interagit directement avec l'éditeur. Le bleu indique le nom d'un script distinct qui fonctionnera avec l'éditeur et tirera diverses commandes via l'API.



Ci-dessus, le niveau de test. Dans ce cas, un sourire est dessiné sur le terrain standard en utilisant une texture préalablement préparée (masque). Il est nécessaire de vérifier que lors de l'utilisation du masque, la peinture ne sera effectuée que le long d'un contour préalablement sélectionné et ne dépassera pas celui-ci.



L'équipe travaillant avec le monde du jeu a écrit son extension pour travailler avec terrane, qui est ensuite insérée dans notre framework. Un nouveau pinceau est créé, qui s'appuiera sur le masque «Pavés», le pinceau est mis en rouge et le calque sélectionné est peint.



En continu, un nouveau pinceau est créé, une intensité différente lui est fixée. Le masque n'est plus utilisé, et dans le cycle, déjà dans une autre partie du niveau, un nouvel élément est dessiné.

Voyons comment fonctionne ce script.

Lien vers la vidéo 38: 42-39: 35

Tout d'abord, le processeur d'actifs démarrera, qui vérifiera l'état de la base de données des actifs et traitera les éléments nouvellement ajoutés si nécessaire. Ensuite, l'éditeur démarre. Le niveau s'ouvrira avec un sourire et un script démarrera qui s'exécutera avec l'éditeur. Il peint le calque sur le masque, puis crée un cercle bleu et commence à prendre des captures d'écran. Par la suite, les captures d'écran seront comparées aux captures d'écran de référence et, si tout est en ordre, le test sera terminé.

Le test prend ces captures d'écran pour comparaison avec les normes. Ici, vous pouvez voir que l'image est clairement passée le long de la frontière.

Arts graphiques


Nous utilisons également notre framework pour tester les graphiques.

Lien vers la vidéo 40: 04-40: 56

Graphiques - l'une des parties les plus difficiles du moteur, qui reprend la majeure partie du code. Vous pouvez et devez tout vérifier - en commençant par des choses simples, telles que la géométrie et les textures, et des fonctionnalités plus complexes - les ombres dynamiques, l'éclairage, les effets de post-traitement. Sur la vidéo dans le coin droit, vous pouvez voir le reflet dans la flaque d'eau - tout fonctionne en temps réel sur notre moteur. Lorsque la caméra vole à l'intérieur, vous pouvez voir des éléments de rendu plus avancés, par exemple, l'éblouissement, des éléments transparents, tels que le verre, ainsi que l'affichage d'éléments tels que des surfaces métalliques. Comment cette fonctionnalité est-elle testée avec des captures d'écran?



C'est notre personnage, Rin. Avec lui, nous testons souvent des pipelines d'artistes. Les artistes créent quelque chose dans leur éditeur (par exemple, un personnage), puis dessinent des textures dessus. Le processeur d'actifs traite les données d'origine à déployer sur diverses plates-formes, et le moteur graphique traitera l'affichage.



Vous avez sûrement souvent rencontré un bug lorsque "les textures ne se chargeaient pas". En fait, il y a beaucoup de problèmes quand quelque chose arrive à l'affichage des textures.



Mais tous sont bien pris en comparant les captures d'écran. Dans la première capture d'écran, vous pouvez voir un bug - certains matériaux ne sont pas bien chargés. Dans ces captures d'écran, le même niveau où se trouvait la moto et la caméra a volé à l'intérieur du café, comme indiqué dans la vidéo plus tôt. Pourquoi tout semble si ennuyeux ici? Parce que les captures d'écran ne sont pas prises à la toute dernière étape du rendu, lorsque le moteur graphique a présenté tous ses effets, mais par étapes. Dans un premier temps, seul le rendu de géométrie et de textures simples est pris: les ombres sont supprimées, les éléments d'éclairage complexes sont supprimés. Si vous testez tout à la toute dernière étape et regardez Diff Image, il sera difficile de dire exactement ce qui s'est cassé.



Si vous le faites par étapes, vous pouvez à peu près comprendre dans quelle partie du moteur graphique quelque chose s'est mal passé. Voici l'algorithme par lequel nous comparons les captures d'écran.



En comparant des captures d'écran, vous pouvez tester des graphiques, des éléments d'affichage, des textures, des matériaux, des shaders.

Je vais donner un exemple d'un bogue de l'ancienne version de notre moteur lorsque nous n'avions pas ce cadre.

Lien vers la vidéo 43: 10-43: 44

Elle concerne le système de végétation. Après avoir ajouté des arbres, la partie graphique commence à dessiner des ombres sous eux. Il faut appuyer sur "Ctrl + Z" ("Annuler"), les arbres disparaissent et les ombres restent. Si vous prenez une capture d'écran au début, lorsque l'arbre est debout et après avoir cliqué sur "Annuler", un tel bug est facile à attraper en mode automatique après avoir comparé avec les captures d'écran de référence d'Avant et d'Après.

En comparant les captures d'écran, le pipeline d'actifs est également très bien testé. Lorsque les artistes ont créé quelque chose dans des éditeurs 3D (Maya, 3dsMax), vous devez vérifier que tout est affiché dans le jeu de la même manière et que rien n'a été perdu: le poulet a des plumes, tous les animaux ont de la fourrure, les gens ont la texture de peau correcte et autres choses.

Lien vers la vidéo 44: 16-44: 52

Sur le côté droit du programme se trouve le processeur d'actifs, qui surveille l'affichage dans le jeu de tout ce que l'artiste a peint. Il nous dira que tout est en ordre avec ces actifs - ils devraient fonctionner. Sur la vidéo, vous pouvez voir que certains arbres sont devenus noirs. Certains s'affichent normalement et certaines textures vertes ont tout simplement disparu. Naturellement, sous cette forme, vous ne pouvez pas libérer un moteur ou des actifs.

Tout ne peut pas être attrapé


Lien vers la vidéo 45: 03-45: 17

Certains types de bogues commencent à se former uniquement lorsque plusieurs éléments interagissent les uns avec les autres. Deux modèles Rin s'affichent normalement s'ils sont retirés l'un de l'autre, mais si vous les rapprochez, les problèmes de géométrie commencent. Malheureusement, ces bogues sont difficiles à détecter même avant l'automatisation. Souvent, ils ne peuvent être remarqués que lorsque les testeurs commencent à faire quelque chose en mode de test exploratoire ou lorsque le moteur tombe déjà entre les mains des clients.



En comparant les captures d'écran, vous pouvez tester l'interface de l'éditeur lui-même.

Composants du jeu




En outre, les captures d'écran peuvent tester certains composants de jeu simples. Un exemple est un niveau simple sur lequel il y a une porte et un script qui, lorsque vous appuyez sur la barre d'espace, démarre la porte pour l'ouvrir et la fermer.

Vous pouvez prendre une capture d'écran au début et à la fin. Si tout correspond, le script qui modifie l'emplacement de l'élément fonctionne correctement.

CHAÎNE


Nous avons rapidement réalisé que les captures d'écran de la même fonctionnalité sont très différentes sur différentes plates-formes, dans certains cas, il peut y avoir des différences sur la même plate-forme en fonction du type de carte vidéo. Comment y faire face, afin de ne pas stocker 100500 captures d'écran? Il existe un outil, Windows Advanced Rasterization Platform est un logiciel de rendu qui vous permet de faire tous les graphiques sans recourir au pilote et à la carte vidéo. En utilisant cet outil, vous pouvez piloter la plupart des tests graphiques fonctionnels sans dépendre des pilotes et du matériel.

Performance


Enfin, le moteur de jeu doit être productif! Les GPU peuvent être testés à l'aide de divers profileurs graphiques, tels que PIX. La RAM peut être testée dans Visual Studio lui-même. De plus, découvrez comment les performances du processeur sont testées à l'aide de l'outil RADTelemetry.

Vous savez ce qu'est un décalage d'entrée?

Lien vers la vidéo 47: 29-48: 21

Input Lag - c'est le délai entre la pression de la touche contrôleur / clavier par le joueur et le moment où le jeu commence à répondre à la pression. Le décalage d'entrée se produit en raison de la transmission de données sur le réseau, lorsque les paquets durent longtemps ou que le serveur répond pendant longtemps, ainsi que dans les moteurs et sans utiliser de réseau. Lorsque quelqu'un se trompe dans le code responsable de l'animation, le décalage d'entrée peut devenir si élevé que le personnage commence à répondre trop tard. En simple approximation, cela se teste assez facilement: un clavier virtuel est ouvert et une vidéo est tournée, sur laquelle sont enregistrés le moment d'appuyer sur la barre d'espace et le moment du début de l'animation.

Nous regardons le nombre d'images par seconde que le moteur donne. Vous pouvez calculer combien chaque trame a pris en millisecondes (1000 / FPS). Si vous lisez la vidéo image par image, vous pouvez calculer le nombre d'images qui se sont écoulées depuis le clic avant que le personnage ne commence à se déplacer. En sachant combien de millisecondes chaque image occupe, on peut calculer que, par exemple, 200 millisecondes se sont écoulées entre la pression d'un espace et le début de l'animation. Avec une réponse humaine standard de 100 millisecondes, c'est trop lent et les joueurs diront immédiatement qu'un tel retard ne vaut rien. Cette méthode de test a ses problèmes. Premièrement, il y aura des erreurs. Par exemple, le clavier virtuel aura un délai. Deuxièmement, dans les jeux, les artistes font souvent des animations pour que le personnage ne commence pas immédiatement à faire le mouvement principal. Il y a la soi-disant anticipation: avant l'action principale,par exemple, en sautant, le personnage se plie d'abord un peu et commence seulement à sauter. Cela peut prendre quelques images. Comment avons-nous combattu cela? Nous avons commencé à tester cette pièce avec une approche plus précise.

Il existe un programme appelé RADTelemetry.

Lien vers la vidéo 49: 44-50: 47

Il vous permet de profiler le processeur. Les cadres verticaux sont présentés ici: n ° 629, 630 - vous pouvez voir combien de temps chaque cadre a pris. Horizontalement, les cœurs de processeur ou les threads d'exécution d'application sont supprimés si l'application est multithread. Si vous cliquez sur l'un des threads, le nom de toutes les fonctions qui se trouvent dans ce thread lors de leur lancement, combien de temps elles ont pris pour s'exécuter à partir du total, combien de fois elles ont été exécutées, sera affiché à gauche. En utilisant cette application, vous pouvez comprendre avec précision le temps qui s'est écoulé depuis le moment où le jeu a enregistré une frappe avant de lancer la fonction Play Animation. Ce programme est capable de mettre ses journaux dans des fichiers texte, puis en les utilisant, vous pouvez dessiner des graphiques de performances utiles de différentes générations dans la distribution du temps.

Et où est AWS ici?


En conclusion, quelques mots sur AWS. D'une part, nous l'utilisons pour conduire nos tests. Nous effectuons des tests sur EC2 et sur les appareils de Device Farm. Les résultats sont ajoutés à la base de données dans S3 et les graphiques sont affichés sur Quicksight. Les statistiques de test peuvent être consultées dans CloudWatch. Étant donné que le moteur est hautement intégré aux services AWS, nous testons également ces intégrations - à la fois manuellement et automatiquement. Par exemple, CloudCanvas est un service qui vous permet de créer des fonctionnalités pour des jeux en réseau sans programmation, c'est-à-dire que sur le serveur, vous pouvez simplement configurer des puces telles que des classements, des tableaux de scores et des réalisations. Pour des choses comme la monétisation des jeux, vous ne pouvez pas rechercher votre programmeur de serveur, mais commencez immédiatement à utiliser CloudCanvas. Amazon GameLift est essentiellement un système évolutif pour les serveurs de jeux.Intégration avec Twitch - lorsque les utilisateurs regardent la diffusion de deux joueurs qui s'affrontent. Un sondage Twitch est créé "Quel joueur soutenez-vous?" - les gens commencent à voter dans le chat, le jeu lit les réponses, et l'un des joueurs (comme dans Hunger Games) peut perdre un bonus supplémentaire ou l'empêcher.

Sommaire


La première chose que nous avons constatée, c'est que dans des projets aussi importants, il n'y a pas de solution miracle unique pour tout automatiser. Dans notre cas, le framework Plug-and-play a bien fonctionné. Nous avons écrit un cadre commun et permis au reste des équipes d'intégrer facilement leurs solutions. À l'aide d'exemples de captures d'écran et de comparaison de végétation, le système a montré comment ces cadres fonctionnent. J'espère que certaines applications et solutions industrielles (telles que le logiciel de rendu de Microsoft ou RADTelemetry.) Fournies dans l'article seront utiles pour les ingénieurs praticiens travaillant dans des jeux ou des systèmes de CAO.

En conclusion, des liens vers tous les outils présentés dans le rapport:



J'espère avoir réussi à dire en quoi les tests de moteurs diffèrent des tests de jeux. Récemment, le processus est allé très loin - tester les moteurs de jeu n'est pas du tout simple, mais il est très intéressant.

Si vous êtes intéressé par le sujet des tests de jeux, nous vous recommandons de consulter d'autres rapports:

More articles:


All Articles