Les tests logiciels sont-ils différents lorsque nous traitons du développement de jeux?

Je lisais cet article sur les différences entre le développement de logiciels en général et le développement de jeux et les auteurs ont fait quelques bons points concernant les tests de logiciels, soulignant, par exemple, que

... les développeurs de jeux hésitent à utiliser les tests automatisés en raison de l'obsolescence rapide de ces tests face aux désirs créatifs changeants des concepteurs de jeux.

Donc, cette lecture m'a fait penser, quels autres aspects des tests de logiciels devrions-nous considérer comme différents ou particuliers lorsque nous traitons / testons un jeu? Quelqu'un a-t-il une expérience avec cela ou quelqu'un a-t-il entendu autre chose à ce sujet?

Les jeux modernes sont en fait une tonne de contenu artistique créatif développé à l'aide d'un moteur de jeu interne ou propriétaire. Le moteur lui-même est testable par unité pour la plupart (rendu, géométrie, physique, modules AI, etc.). De même, des tests simples peuvent également être attachés à des parties individuelles du contenu développé. Cela signifie que les tests unitaires et en boîte blanche sont en effet réalisables et réussis.

En ce qui concerne le «produit dans son ensemble», un jeu est une simulation. Il pourrait avoir une complexité plus générative qu'un simple programme d'entreprise. Pensez à des mondes générés sans fin, uniques et procéduraux par rapport à un planificateur de ressources d'entreprise avec des comportements bien planifiés et dénombrables. Autrement dit, le nombre de façons uniques possibles de faire quelque chose dans le contexte des jeux, peut être mathématiquement, très très grand. En fait, il est considéré comme un argument de vente pour les jeux.

Ajoutez à cela le fait que la sortie finale est purement audiovisuelle et qu'il n'y a pas de norme déterministe d'exactitude absolue de cette sortie. Les puces GPU n'ont vraiment pas besoin d'effectuer des calculs précis, juste beaucoup de calculs, même si certains ne sont pas précis.

Et enfin, l'objectif principal est le divertissement . Les joueurs sont d'accord avec les pépins s'il exécute plus de 60 FPS, a l'air génial et a des heures interminables de contenu divertissant.

Cela place simplement les idées de test automatisées traditionnelles de la boîte noire dans la région "pas si tangible et en vaut la peine" lorsqu'elles sont appliquées aux jeux.

Cependant, il y a eu récemment des tentatives pour former des NN à jouer à des jeux , ce qui est en fait une forme de test de singe exploratoire et auto-apprentissage.

Cela fait de nombreuses années que je n'ai pas gamedev mais en plus de la bonne réponse, il y a certaines choses que je veux ajouter et détailler.

Tout d'abord, il a déjà été mentionné que la sortie est juste visuelle et auditive par rapport aux contraintes strictes "critiques en FPS" et aux budgets de calcul / mémoire. Les idées de correction deviennent floues lorsque les questions sont plus du genre: "Est-ce que ça a l'air bien? Est-ce que ça marche bien sans bégaiement? tandis que les développeurs peaufinent et ajustent et rapprochent tandis que les collaborations concepteur / développeur conduisent à des choses qui semblent et sonnent légèrement différentes à chaque itération rapide.

Un autre est que les testeurs peuvent être géniaux! Je n'ai jamais trouvé de groupe de testeurs plus dévoué dans un autre domaine, car ils veulentpour tester le logiciel. Ils s'amusent. Ils sont accros et dorment à côté de l'ordinateur tout en explorant tous les coins et recoins de votre jeu. Il devient assez facile de découvrir même les pépins les plus obscurs lorsque les gens sont amusés à tester minutieusement tous les coins du logiciel tout en étant pratiquement accro. Dans mon industrie actuelle, les testeurs sont un peu plus difficiles à travailler car beaucoup d'entre eux sont des professionnels qui lient leurs moyens de subsistance au logiciel, et ils comptent donc sur une poignée de fonctionnalités pour faire leur travail et ne sont pas nécessairement intéressés par l'épuisement chaque coin et recoin tout le temps. Naturellement, lorsque nous ne pouvons pas compter autant sur les testeurs humains, nous avons besoin de tests plus automatisés.

Encore un autre est que la base de code d'un jeu n'est généralement pas maintenue, modifiée et étendue pendant des années et des années. Ce n'est pas comme si les développeurs de Super Mario qui l'avaient initialement développé en assemblage 6502 ont dû maintenir quelque chose ressemblant à ce code original longtemps après la sortie du jeu. Doom 3 utilise probablement zéro ligne de code (ou ferme) de Doom 1. S'il y a une franchise continue, les nouveaux jeux ressemblent plus à des «suites» qu'à des «mises à niveau». La plupart des jeux sont livrés et peuvent éventuellement publier des correctifs, des DLC, puis le code est terminé. C'est un contraste énorme par rapport à mon industrie VFX où j'ai travaillé sur la maintenance du code datant de l'époque d'Amiga qui avait été porté et maintenu pendant des décennies. Les jeux ne font généralement pas

L'une des raisons de cette nature éphémère des bases de code de jeu est qu'elles sont tellement liées au matériel. Lorsqu'elles sont combinées à leur nature de pointe et à leurs exigences critiques en matière de FPS, elles ne peuvent souvent pas être développées d'une manière qui résume les détails du matériel, pas même de façon rapprochée. Ils sont souvent écrits très spécifiquement pour la génération cible de matériel, et il ne faut généralement pas longtemps avant que la PS3 ne soit remplacée par une PS4 qui devient alors obsolète et remplacée par une PS5, etc., et tout cela très rapidement. Les capacités matérielles jouent un rôle si essentiel dans la conception et le développement du jeu qu'il ne vaut généralement pas la peine d'essayer de conserver le même code écrit pour PSX que pour PS4, par exemple la plupart des franchises de jeux qui durent des générations écrivent toujours leurs moteurs de nouvelle génération. en grande partie de la base pour le matériel le plus récent.

Avec une base de code de courte durée, le temps de maintenance est limité (c'est-à-dire un temps limité pendant lequel le code doit être modifié). Avec un temps limité pour le changement du code qui ne s'étale pas sur des années avec l'étendue du moteur de plus en plus grand à chaque mise à niveau, et combiné avec le fait que les jeux sont loin d'être critiques pour la mission, il n'y a pas un tel absolument besoin critique d'appliquer les tests unitaires et d'intégration les plus exhaustifs. Il n'y a aucun avantage à le faire en garantissant l'intégrité des changements futurs si de futurs changements ne seront pas effectués, et l'aspect test unitaire et refactorisation des bases de code héritées est naturellement hors de propos s'il n'y a pas "héritage" en premier lieu.

Un autre petit problème qui n'est pas toujours pertinent est qu'un jeu ne peut cibler qu'une gamme très étroite de matériel sans ports de bureau. Dans ces cas, une énorme source de problèmes imprévisibles dans ces contextes, à savoir les utilisateurs exécutant le logiciel avec un matériel et des pilotes radicalement différents, est éliminée.

Cela dit, les tests d'intégration au niveau le plus élevé / le plus grossier ont tendance à être plus immédiatement utiles. Par exemple, de nombreux jeux peuvent utiliser un moyen d'enregistrer la façon dont l'état du jeu évolue au fil du temps pour les "rediffusions". De telles fonctionnalités de relecture peuvent garantir que le jeu est déterministe et peuvent également être utilisées comme une forme d'outil de test à lui seul pour rejouer une session de jeu enregistrée précédemment par quelqu'un d'autre.

J'ai également rencontré des gamedev travaillant dans de petits studios qui ont fait des choses comme écrire des bots pour leur jeu et ont fait jouer les bots à leur vitesse maximale et ont exécuté cette simulation, rencontrant à l'origine un crash obscur après un jour ou deux, puis l'ont corrigé, puis a de nouveau exécuté la simulation et a répété jusqu'à ce qu'il n'y ait plus de crashs d'exposition, même après l'avoir exécutée pendant des semaines. Il existe donc des types intéressants d'approches pragmatiques comme celles que j'ai vues de gamedevs pour tester leurs logiciels, mais souvent d'une manière qui ressemble au niveau le plus grossier de tests d'intégration et de simulation très proche de la façon dont les joueurs interagissent réellement avec le jeu.

Enfin, ces gros moteurs de jeu AAA commencent à ressembler à un tout autre type de bête: ils ont une durée de vie plus longue, résument un peu mieux le matériel, avec des bases de code plus grandes et des périodes de maintenance plus longues tandis que leurs éditeurs de niveau commencent à ressembler à des environnements de développement à part entière. J'imagine que ces gros moteurs nécessiteraient probablement une procédure de test plus approfondie, surtout si le temps de maintenance de leur code augmente considérablement. Beaucoup de studios de jeux n'écrivent pas d'énormes moteurs de jeux AAA: ils les octroient des licences ou développent un petit moteur propriétaire qui est considérablement plus petit et ne sera pas maintenu pendant des années.