Test automatisé de jeux [fermé]

Existe-t-il des méthodes de test automatisé des jeux?

Des expériences spécifiques sont appréciées, avec des informations pertinentes sur le projet, telles que la plate-forme et le type de jeu, si cela vous aide à clarifier.

Jeu indépendant à une personne. C’était un jeu de tank multijoueur avec un terrain destructible, et le code du terrain et de la collision destructibles s’avérait quelque peu floconneux.

J'ai fini par truquer des IA de base stupides (par "stupide", je veux dire "absolument idiot" - ils choisiraient au hasard "conduire vers un tank ennemi", "s'éloigner d'un tank ennemi" et "conduire dans une direction aléatoire". ", tout en tirant de manière aléatoire sur l'arme principale) et en jouant le jeu au débit d'images maximal tout en enregistrant les touches du clavier. J'ai environ 10-15 fois en temps réel. Le code a été fortement assumé. Ainsi, en cas de problème, le journal de pression des touches tout entier sera transféré sur le disque avec un rapport d'erreur et la valeur de départ initiale aléatoire. Je pourrais alors aller rejouer le journal de frappe pour dupliquer exactement l'état, ou tout simplement déboguer à partir du rapport d'erreur.

Je l'ai laissé fonctionner constamment pendant des mois. Au début, il ne restait que rarement une heure sans se briser - je devais rester assis là et le garder pendant une semaine, tuant plusieurs bogues obscurs par jour. Finalement, il est arrivé au point où il a fonctionné pendant une semaine entre les échecs, ce qui représente environ 1500 heures de jeu par crash.

C'était inestimable et je le recommande vivement.

Pour un MMO sur lequel j'ai travaillé (100 développeurs, orienté PC), nous avons essayé d'ajouter une grande variété de tests automatisés avec un succès variable. Voici ce qui a fonctionné:

• Les tests de base effectués au cours de notre processus de construction automatisée ont été un gain considérable. Cela incluait des tâches telles que la création d'un personnage, le transfert de cartes, l'exécution de tests d'interface utilisateur scriptables et la recherche du comportement attendu. Cela a attiré un grand nombre de bugs avant qu’ils ne parviennent au reste de la société.
• Du côté de l’infrastructure de serveur, nous avons développé un ensemble de différents tests automatisés simulant des transactions de serveur MMO typiques. Nous pourrions ensuite les reproduire dans diverses circonstances afin de comparer les performances ou d’assurer la sécurité. Au fil du temps, ces tests sont devenus de plus en plus précis jusqu'à ce qu'ils se transforment en une lecture de données enregistrées en direct
• Nous avons écrit un "faux joueur" qui errerait au hasard dans le monde, sauterait, tuerait des choses et dirait des choses aléatoires sur le chat. Cela a trouvé un grand nombre de problèmes de physique et d'infrastructure.

Ce qui n'a pas fonctionné:

• Nous avons essayé d’ajouter au constructeur automatique des tests automatisés très spécifiques, axés sur le combat, mais cela n’a fondamentalement jamais fonctionné. Cela fonctionnerait environ 3 jours après sa mise en œuvre, jusqu'à ce qu'un designer ou un artiste modifie quelque chose et que le test échoue et que les alarmes de génération non réussies soient rejetées. 90% du temps ce n'était pas un vrai problème. Ces tests étaient trop fragiles et il est parfois impossible de tester un jeu spécifique sur une carte spécifique avec des pouvoirs spécifiques.
• Nous avons essayé de mettre en œuvre un test de performance automatisé comparant les performances du client (FPS moyen, etc.) aux performances enregistrées la semaine précédente. Cela était également assez fragile, car les démonstrations que nous avons utilisées avaient tendance à pourrir assez souvent, et il était difficile de déterminer si un ralentissement était causé par une perte de performances réelle ou par un effet secondaire du processus de test.

Travailler sur un jeu de stratégie 4x avec des combats en 3D (pensez que Homeworld rencontre Masters Of Orion) qui, malheureusement, n’a jamais vu le jour, la société étant à court de fonds ..

Je me suis toujours assuré que tu pouvais jouer au jeu sans joueurs humains afin que nous puissions laisser le jeu en marche du jour au lendemain.

Nous pouvions désactiver le combat 3D (simplifié pour obtenir un résultat aléatoire) et laisser le moteur de stratégie d'intelligence artificielle en marche. Cela a trouvé de nombreux bugs et problèmes. Montrez non seulement des bugs stopper, mais aussi des bugs de stratégie dans lesquels les stratégies (par exemple) d'IA se retrouveraient dans une impasse et passeraient des milliers de tours à ne pas faire "la bonne chose". Il était difficile de repérer ce type de bugs juste "en train de jouer".

Sur un jeu de tir à la première personne sur lequel j'ai travaillé (Descent 3 - Linux / Mac / Windows, environ 30 personnes dans l’équipe en 1999), la capacité d’enregistrement et de lecture de démo s’est avérée extrêmement utile. J'ai créé une option permettant de lire la démo aussi rapidement que le jeu pouvait générer des images, ce qui est devenu un excellent moyen de vérifier les performances après de nombreuses modifications.

Il a également exercé une grande partie du code au-delà du système de rendu, donc c'était un bon contrôle de cohérence. Après avoir apporté de nombreuses modifications, je ne pouvais lancer que la démonstration de 10 minutes de jeu. Plusieurs fois, cela attraperait un virus dans un domaine que je n'aurais pas pensé à vérifier moi-même.

Un jeu de tir Openworld (x360, PS3, PC) utilisait un test de fumée rapide sur le serveur de compilation: il chargeait le jeu, passait par le front-end, exécutait l'avatar, transmettait une capture d'écran, puis quittait. Si cctray détectait la sortie propre, la construction était un succès.

Nous l'avons exécuté pendant à peu près la dernière année du projet et avec une équipe d'environ ~ 100 développeurs.

C’était efficace pour attraper des bugs de démonstration mais il était facile de créer une version qui réussissait, mais qui échouait dans la plupart des "vrais" niveaux, ou ne fonctionnait pas en multijoueur ou nobulait l’intelligence artificielle, donc ce n’était pas parfait. Cela valait vraiment la peine d'être fait.

Depuis que je suis parti, j'ai entendu dire qu'ils avaient commencé à utiliser une plus grande gamme d'essais de fumée, exploités par plusieurs ordinateurs. Apparemment, la maintenance des fumigestes est un problème, et une petite équipe se consacre à la maintenance des serveurs et des logiciels de compilation, donc je ne peux pas dire si cela a été un succès ou non.

Mon expérience des tests automatisés au cours du développement de Crysis 2 est disponible ici: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

Sommaire:

• Les tests automatisés ont amélioré la stabilité des produits livrables, augmentant la productivité des créateurs de contenu et des ingénieurs.
• Les tests automatisés sont un outil efficace pour améliorer la qualité du code et réduire les risques de travail supplémentaire
• L’industrie du jeu dans son ensemble est très réactionnaire en général, les tests automatisés répondent à plusieurs arguments irrationnels contre
• N'appelez pas cela de test, appelez quelque chose d'autre, presque n'importe quoi d'autre (Regardez le développement basé sur le comportement)
• Soyez flexible, passer de bons tests est difficile et nécessite des compétences qui ne sont pas largement disponibles dans l'industrie du jeu.

Le développement de jeux est en fait l'un des cas où les tests unitaires me semblent logiques, car les interactions entre systèmes discrets sont si courantes. La conception par contrat en fait naturellement partie, et devrait être planifiée dès le premier jour du développement, mais je ne vois pas pourquoi elle ne pourrait pas être mise en œuvre plus tard si les moyens de le faire existent.

La partie difficile est, bien sûr, les tests d'intégration. Beaucoup de jeux peuvent être testés simplement en démo-boucle, ou autre chose, mais conceptuellement, il est assez facile de déboguer - là où je serais plus intéressé, je passerais mon temps à exposer les bugs qui se produiront lorsqu'un joueur fait quelque chose, avec l'état d'esprit qu'un bogue que le joueur ne voit jamais est évidemment moins important qu'un bogue que le joueur voit.

Ce qui est assez difficile, évidemment. Les tactiques qui fonctionnent sur d'autres applications (fuzzing, échec attendu / échec attendu, etc.) ne fonctionnent pas aussi bien ici. Dans les systèmes scriptables, il semble que la voie à suivre (voir la réponse de JZig) consiste à créer un ensemble de scripts de test pour simuler un lecteur. Mais tester spécifiquement les choses qu'un joueur peut rencontrer me semble directement le meilleur endroit pour concentrer votre temps à la fois pour des tests humains et automatisés.