Le développement piloté par les tests est-il viable dans le développement de jeux?

23

En tant que certifié Scrum, j'ai tendance à privilégier les méthodologies Agiles lors du développement d'un système, et même à utiliser un canevas du framework Scrum pour gérer mon travail quotidien.

D'ailleurs, je me demande si TDD est une option dans le développement de jeux, si elle est viable?

Si je crois à cette question GD, TDD n'est pas très utile dans le développement de jeux.
Pourquoi MVC et TDD ne sont-ils pas davantage employés dans l'architecture de jeu?

Je viens de la programmation industrielle où de grands projets avec de gros budgets doivent fonctionner sans problème, car cela pourrait entraîner des scénarios catastrophiques si le code n'était pas rigoureusement testé à l'intérieur comme à l'extérieur.

De plus, le respect des règles Scrum encourage le respect des dates d'échéance de votre travail alors que chaque action dans Scrum est limitée dans le temps! Donc, je suis d'accord quand dans la question liée ci-dessus, ils disent d'arrêter d'essayer de construire un système et de commencer à écrire le jeu. C'est tout à fait ce que Scrum dit, essayez de ne pas construire le système parfait, d'abord: faites-le fonctionner à la fin du Sprint. Ensuite, refactorisez le code tout en travaillant dans le deuxième Sprint si nécessaire!

Je comprends que si tous les départements responsables du développement du jeu n'utilisent pas Scrum, Scrum devient inutile. Mais considérons un instant que tous les départements utilisent Scrum ... Je pense que TDD serait bien d'écrire du code sans bug, même si vous ne voulez pas écrire le système / jeu "parfait".

Ma question est donc la suivante:

Est-ce que TDD est viable dans le développement de jeux de toute façon?

— Will Marcouiller
source

Qu'est-ce que la discussion de cette question va ajouter au-delà de la question que vous avez liée?

Je présente le cadre Scrum de gestion de projet dans le développement de logiciels Agile et je discute de ce que Scrum veut d'un développeur pendant un Sprint, rendant ainsi TDD viable en option. Je veux obtenir le point de vue des autres sur le sujet du point de vue Scrum, pas seulement sous l'aspect TDD ou MVC. Je veux comprendre comment le TDD n'est pas viable lorsqu'il est argumenté de ce côté de la médaille, à part le simple fait de considérer le TDD lui-même comme une approche autonome.

— Will Marcouiller

@Will TDD == Conception descendante ou conception pilotée par les tests? Je pensais à Top Down et j'allais donner une réponse sur la gérabilité à long terme, mais j'ai ensuite vu que l'autre interprétation était d'interpréter le TDD d'une manière que je n'étais pas ...

— James

@James: Test Driven Development.

— chaos

@James: Désolé pour la confusion! Je ne connaissais pas l'autre sens de l'acronyme, car je pensais au développement logiciel agile avec Scrum.

— Will Marcouiller

11

C'est certainement viable, bien que beaucoup de programmeurs de jeux n'aient pas encore vraiment adhéré à l'idée, ou aient une bonne compréhension de la façon de tester des systèmes complexes. Je m'avoue que je l'utilise rarement, sauf pour les systèmes non liés au gameplay qui sont faciles à tester.

Attendez-vous à utiliser beaucoup d'objets fictifs. En raison du lien entre de nombreux systèmes, il est difficile de tester des composants individuels de cela.

De plus, beaucoup de choses ne peuvent pas être testées de manière approfondie. Comment testez-vous, disons, un système de particules? Comment testez-vous que votre système d'animation fonctionne correctement? Beaucoup de choses sont de nature visuelle et ne sont pas évidentes (du moins pour moi) quant à la façon de faire des tests appropriés.

Il y a cependant beaucoup de choses qui ne sont pas nécessairement des tests unitaires au sens traditionnel du terme, mais qui existent en tant que "tests" pour des fonctionnalités spécifiques. Des choses comme les niveaux de test pour la navigation par IA sont assez courantes, mais ne sont pas nécessairement les choses les plus faciles à automatiser.

Il y a certains aspects des jeux qui peuvent (et devraient probablement) avoir des tests unitaires écrits pour eux. Tout type de système générique de «lecture de fichiers» doit être testé. Peut-être avoir des tests pour l'initialisation de choses matérielles (surfaces 3D, etc.). Peut-être avoir des serveurs fictifs et tester votre code d'interaction client / serveur. Des choses comme ça.

— Tetrad
source

9

Ce sont d'excellentes propositions pour la présence de tests automatisés, mais pas du tout pour un développement piloté par les tests.

1

Avis intéressant, Tetrad! Merci pour ton grain de sel. Vous demandez comment tester l'animation visuelle? Difficile à dire pour les systèmes 3D, car je n'ai encore jamais écrit un seul jeu, peut-être après que certains aient développé quelques petits jeux! D'ailleurs, en 2D, j'ai souvent vu des objets représentés par une matrice, et des analyseurs matriciels pour restituer l'image à l'écran. Par conséquent, faire en sorte qu'après avoir appuyé sur une touche directionnelle, les bonnes informations trouvées au bon endroit dans la matrice résultante puissent être un début, je suppose. Je ne connais pas encore assez les composants visuels d'un jeu, et je le ferai certainement cette année! =)

— Will Marcouiller

Je suis de retour après un codage pour dire que j'ai répondu à une question cette semaine (ma première sur GD! =)) Qui nécessitait une connaissance des concepts de la POO. L'OP voulait déplacer un serpent sur Keys.Down, Keys.Leftetc. Que dire que le jeu sait où l'utilisateur veut que le serpent d'aller, et le serpent doit aller là où le jeu , il dit à, bien que ce soit seulement le serpent qui sait comment de se déplacer dans les différentes directions, donc aussi de sa position dans le jeu. Cela dit, à mon humble avis, rend la Snakeclasse testable! (A suivre ...)

— Will Marcouiller

Non seulement il est testable, mais il est maintenant un bon candidat pour TDD. Disons que le serpent est initialisé à la position Vector2.Zero, avec une vitesse 10.0fsur les axes X et Y dans ce jeu 2D. La première question est: est-il positionné à sa position initiale supposée et comment le tester? Ensuite, vous pensez que la Positionpropriété doit être exposée publiquement. Deuxièmement: comment le faire bouger? Les méthodes de mouvement doivent être bonnes, vous devez donc écrire un test pour chaque méthode de direction MoveDown, MoveLeftetc. Maintenant, allez écrire votre déclaration de méthode et voyez si le test se plaint. Ensuite, revérifiez la position du serpent

— Will Marcouiller

après un MoveDownappel de méthode! Puisque vous savez que la Positionpropriété est minutieusement testée, c'est un membre sur lequel vous pouvez compter! Vous pouvez deviner la suite ici! ;-) C'est-à-dire que les composants visuels ne peuvent certainement pas être testés, mais le serpent devrait ressembler à un serpent, tout dépend du type de serpent que vous voulez dans le jeu. L'artiste dessinant le serpent devrait prouver suffisamment de satisfaction avec son dessin du serpent, qui ne doit pas être testé par TDD, bien sûr! Mais sa position par rapport à d'autres objets le peut, ainsi que la classe qui représente ce serpent. En fait, TDD

— Will Marcouiller

11

Je ne pense pas que TDD, en tant que tel, soit approprié comme base pour le développement de jeux. Les tests unitaires automatisés dans le cadre de la méthodologie, bien sûr, mais trop de préoccupations clés du développement de jeux sont subjectives et ne peuvent pas être testées par machine pour que les tests soient le moteur du développement. Comment allez-vous écrire un test scripté pour savoir si un mécanicien de jeu est amusant? Qu'un niveau est visuellement attrayant? Même qu'un niveau prend environ 15 minutes à un joueur typique? TDD s'adapte aux situations où la maturité d'un projet peut être mesurée quantitativement en termes de conformité à une spécification, et ce n'est tout simplement pas le développement de jeux.

— le chaos
source

3

Que voulez-vous dire lorsque vous dites que le développement de jeux n'est pas conforme aux spécifications? Mon point est que vous devez savoir quel genre de jeu vous écrivez quand vous voulez en écrire un. En tant que telles, les spécifications, les exigences doivent être écrites sous forme de caractéristiques ou similaires; Prenons un exemple de Product Backlog dans Scrum. Vous connaissez les user stories que vous devrez développer dans votre jeu afin d'écrire le jeu attendu! Ensuite, pour un autre exemple, vous devrez peut-être détecter des collisions dans un jeu de combat, ce sont des choses testables! Que le jeu soit amusant dépend davantage de l'histoire que de la programmation, à mon humble avis.

— Will Marcouiller

@Will Marcouiller: Je ne veux pas dire que nous n'avons pas de spécifications ou que nous ne pouvons pas mesurer leur conformité, mais que moins de ce qui est important dans le projet peut être spécifié de manière significative que dans d'autres types de développement. Vous pouvez écrire "le jeu devrait être amusant" dans votre spécification, mais ce n'est pas une spécification ayant une signification technique. Vous pouvez et devez tester ce qui peut être testé, mais le point essentiel de TDD est que le test ne fait pas seulement partie du processus, c'est la base entière du processus, un état d'esprit fondamental, et je ne vois pas champ subjectif.

— chaos

2

@Will Marcouiller, je suis fortement, fortement, en désaccord avec le fait que le plaisir du jeu se résume à l'histoire. Tout le plaisir du jeu se résume au gameplay, l'histoire n'est qu'un bonus.

— AttackingHobo

1

@ Will: Non, il dit que le plaisir qu'un utilisateur tire d'un jeu ne peut pas être déterminé via un test automatisé, et que les jeux ont de grandes quantités de choses qui ne peuvent être testées qu'en envoyant le jeu entre les mains du consommateur.

— DeadMG

1

@DeadMG: C'est plus vrai que quiconque ne le souhaiterait, mais mon argument (pas nécessairement celui d'AttackingHobo) implique le fait que le processus de développement lui-même doit incorporer des tests, par des concepteurs et des producteurs et des développeurs et des testeurs, qui ne peuvent pas être quantifiés dans une unité test, c'est à voir avec la qualité de l'expérience et la sensation et le style et l'effet esthétique que le jeu crée. Dire aux gens qu'ils font du TDD alors que c'est une partie si importante du développement, c'est simplement leur mentir.

— chaos

6

Il est un peu difficile de déterminer exactement ce que vous demandez, car le titre est purement sur TDD, mais vous semblez faire de Scrum une partie intégrante de la question également - et si je comprends bien, l'un n'exige pas l'autre.

Si je crois à cette question GD, TDD n'est pas très utile dans le développement de jeux.

C'est exact. Je ne pense pas en avoir jamais entendu parler dans la pratique de l'industrie des jeux. (Mais je n'en ai jamais entendu parler non plus en dehors de l'industrie des jeux - juste par des particuliers.)

Je viens de la programmation industrielle où de grands projets avec de gros budgets doivent fonctionner sans problème, car cela pourrait entraîner des scénarios catastrophiques si le code n'était pas rigoureusement testé à l'intérieur comme à l'extérieur.

Les jeux n'ont pas besoin de fonctionner parfaitement. Il y a donc beaucoup moins d'accent sur l'exactitude du code. TDD ne garantit pas l'exactitude du code, mais certaines personnes pensent qu'il réduit l'inexactitude. Je n'ai pas encore de preuve de cela.

De plus, le respect des règles Scrum encourage le respect des dates d'échéance de votre travail alors que chaque action dans Scrum est limitée dans le temps!

Je n'ai jamais vu de méthodologie qui n'encourageait pas à respecter les dates d'échéance ou à avoir des actions qui n'étaient pas limitées dans le temps. Le problème est que quelle que soit la méthodologie utilisée, l'estimation de la complexité d'un logiciel est assez difficile. Ce n'est pas impossible, mais son estimation précise n'a pas grand-chose à voir avec le processus. Si ma tâche est d'ajouter un nouveau panneau GUI, ou de corriger un bogue avec l'animation, ou d'ajouter une nouvelle statistique aux personnages, alors l'utilisation de Scrum ne va pas du tout accélérer cela, et l'utilisation de TDD va pour ralentir la tâche (au bénéfice éventuel d'une réduction ultérieure des tâches de maintenance). Ils ne vont certainement pas faciliter l'estimation de la durée de la tâche.

Je pense que TDD serait bien d'écrire du code sans bug, même si vous ne voulez pas écrire le système / jeu "parfait".

S'il est prouvé que TDD écrit un meilleur code que d'autres méthodes, alors oui.

Y a-t-il une preuve de cela? Le fait que l'industrie pourrait l'utiliser n'est pas une preuve. L'industrie est bien connue pour produire un code médiocre qui est livré en retard. L'absence d'exemples de grands projets TDD qui ont échoué ou qui ont pris du retard est peut-être dû au fait que c'est une nouvelle approche et que peu de gens ont déjà terminé un tel projet. (Et ceux qui sont en retard ... peuvent encore fonctionner.)

Est-ce que TDD est viable dans le développement de jeux de toute façon?

Viable? Bien sûr. Bénéfique? Cela reste à prouver.

— Kylotan
source

1

Malheureusement, TDD et Scrum sont encore mal compris. Et cela est vrai pour les projets existants qui ne permettront ni d'accélérer les corrections de bogues ni d'autre. Scrum est un cadre pour développer des systèmes complexes, comme un jeu semble l'être. Scrum encourage la correction de bugs d'un Sprint à un autre afin qu'ils ne s'accumulent jamais. TDD vous place du côté de l'utilisateur. Par utilisateur, je veux dire des collègues programmeurs qui utiliseront votre code. Cela vous oblige à réfléchir à la façon dont il doit être utilisé pour rendre votre code facile à utiliser pour les autres. Par conséquent, cela conduit à une meilleure conception, par expérience. Cela dit, vous avez des opinions intéressantes sur le sujet.

— Will Marcouiller

1

Forcer les bogues à ne pas s'accumuler fait juste glisser les fonctionnalités - vous ne pouvez pas produire plus de temps comme par magie. Ma compréhension est que Scrum n'a de toute façon aucune méthode particulière spécifique aux bogues. Quant à TDD vous obligeant à réfléchir à la façon dont les autres utiliseront votre code, ce n'est pas la seule façon de procéder. Par conséquent, ce n'est pas nécessairement mieux, et certainement pas nécessairement l'utilisation la plus efficace du temps.

— Kylotan

1

Pour info, Noel Llopis utilise TDD pour ses jeux indépendants, et son ancienne société High Moon Studios l'a largement utilisé. Je n'ai pas de citation, désolé.

— tenpn

Vous avez de bons points intéressants à lire! Merci pour votre contribution. Néanmoins, je voudrais ajouter que TDD est encore une autre approche tout comme XP (programmation extrême). Et oui, Scrum ne fournit aucune méthode particulière spécifique aux bugs, et investit plutôt sur l'auto-organisation de l'équipe (des développeurs). Scrum ne vous dit pas comment faire les choses, il dit seulement ce qui doit être fait. C'est l'engagement de l'équipe de parcourir ce qui doit être fait. Scrum ne parie que sur des équipes interfonctionnelles auto-organisées. C'est l'équipe qui décide comment les fonctionnalités doivent être développées et testées, etc.

— Will Marcouiller

(continuer ...) J'ai répondu à ma première question cette semaine sur les cours ici sur GD. L'OP voulait apprendre à faire bouger son sprite sur les touches directionnelles. Étant à l'aise avec les concepts de POO, j'ai compris que je devrais peut-être utiliser des cours pour développer mon premier jeu en utilisant XNA. Cela dit, ma Spacecraftclasse devient une classe entièrement testable avec des méthodes et des propriétés. C'est le genre de choses qui peuvent absolument, à mon humble avis, être entièrement testées en utilisant TDD. Disons que vous avez besoin d'un vaisseau spatial, puis vous écrivez les tests pour ce dont vous avez besoin pour effectuer un test à la fois.

— Will Marcouiller

4

désolé pour mon pauvre anglais et désolé pour mon point de vue biaisé: je ne suis pas un game designer mais un codeur.

Je pense qu'il y a un malentendu dans cette discussion. je vais parler de TDD sous une forme plus générale, le soi-disant BDD. Le développement axé sur le comportement n'est pas un moyen de tester un projet (les tests sont quelque chose comme des effets secondaires). BDD est un moyen de concevoir , un moyen de refactoriser et de concevoir des logiciels pendant toute la production (voir certaines devises comme KISS, "garder la qualité", "tester tôt, tester souvent") et pas dans une phase seule. BDD est l'opposé de certains processus logiciels classiques comme le processus en cascade ou d'une autre méthodologie itérative pour créer des logiciels.

Un autre point est que les tests automatiques sont pour ces fonctionnalités qui pourraient être testées automatiquement par une machine de calcul. il n'y a pas de test pour le plaisir dans les jeux, et il n'y a pas de test pour l'utilisabilité d'une interface utilisateur graphique. le plaisir ou l'utilisabilité sont des matériaux pour d'autres emplois et non pour le développement de logiciels comme le concepteur d'interaction, le monde et le niveau d. de la même manière que les parties artistiques (modélisation, texturation, etc.) sont destinées aux artistes qui utilisent les ordinateurs comme outil de créativité - évidemment, ces travaux pourraient être exécutés par la même personne qui écrit du code, mais ce n'est pas la question. la physique pourrait être testée, des algorithmes d'optimisation pourraient être testés, des comportements d'objets singuliers pourraient être testés (avec des simulacres, des talons et des mannequins comme mentionné précédemment)

la dernière pensée est que, à mon humble avis, non seulement la conception de jeux, mais tout le code d'écriture est un art.

— nkint
source

4

Voici une étude de cas d'une personne qui pense que TDD et gamedev se mélangent plutôt bien:

http://powertwenty.com/kpd/downloads/TestDrivenDevelopmentInPython.pdf

Certes, il s'agit d'un petit projet dans Pygame, mais il donne l'idée de quelles parties peuvent être testées avec un jeu graphique et lesquelles ne le peuvent pas. J'ai été surpris de voir ce qui pouvait être fait avec TDD dans ce scénario.

— Brandon
source

1

Sans comparaison avec un groupe de contrôle qui a fait le même projet (cloner un jeu d'arcade trivial existant dans un langage de très haut niveau), il ne dit pas si TDD est efficace ou non. Il dit simplement qu'il a utilisé TDD.

3

Non, le développement piloté par les tests n'est pas adapté au développement de jeux. Bien sûr, vous pouvez écrire des tests pour certaines parties que vous souhaitez tester, mais le processus de développement de jeu est complètement différent du développement piloté par les tests qui nécessite d'avoir des spécifications exactes avant de commencer.

Les jeux ont rarement des spécifications exactes au démarrage. Et s'ils le font, ils changent et évoluent toujours au cours du processus de développement.

La conception de jeux est un art, vous ne pouvez pas avoir de tests spécifiques pour savoir quand l'art est bon ou complet.

— AttackingHobo
source

Ne pensez-vous pas que le facteur plaisir devrait être pris en compte lors de l'analyse du jeu lui-même, de l'analyse fonctionnelle ou similaire? Vous pouvez configurer un ensemble de fonctionnalités qui, ensemble, rendront le jeu amusant à jouer, et ces fonctionnalités sont ensuite testables! J'essaie seulement de présenter différentes opinions pour approfondir le sujet et les arguments que vous proposez. Merci pour votre contribution! =)

— Will Marcouiller

3

Beaucoup de développement se résume à peaufiner de petites choses et à voir à quel point elles sont amusantes à jouer. Vous ne pouvez pas tester ces choses à moins qu'elles ne soient entièrement gravées dans la pierre. Et tester un système après l'avoir fait n'est pas du TDD, c'est du test, mais pas du développement piloté par des tests.

— AttackingHobo du

2

Si vous pensez que la plupart des projets du monde réel ont des spécifications exactes au démarrage, vous n'avez probablement pas travaillé sur beaucoup de projets du monde réel.

— BlueRaja - Danny Pflughoeft