Pourquoi MVC et TDD ne sont-ils pas davantage employés dans l'architecture de jeu? [fermé]

Je commencerai par dire que je n'ai pas cherché beaucoup de sources de jeu ni construit beaucoup de jeux.

Mais essayer d’employer des pratiques de codage «entreprise» dans les applications Web et consulter le code source du jeu me fait très mal à la tête: «Que fait cette logique de vue dans la logique métier? Cela nécessite un refactoring ... "

Cela m'inquiète alors que je suis sur le point de démarrer un projet de jeu et je ne suis pas sûr que d'essayer de créer un processus mvc / tdd va nous entraver ou nous aider, car je ne vois pas beaucoup d'exemples de jeux qui l'utilisent. ou beaucoup de pression pour de meilleures pratiques architecturales dans la communauté.

Ce qui suit est un extrait d’un excellent article sur les jeux de prototypage , bien que j’ai semblé être exactement l’attitude que beaucoup de développeurs de jeux semblent adopter lors de la rédaction du code de jeu de production:

Erreur n ° 4: Construire un système, pas un jeu

... si vous vous retrouvez à travailler sur quelque chose qui ne fait pas avancer directement votre progression, arrêtez-vous là. En tant que programmeurs, nous avons tendance à essayer de généraliser notre code, de le rendre élégant et de pouvoir gérer toutes les situations. Nous constatons que la démangeaison est terriblement difficile, mais nous devons apprendre à le faire. Il m'a fallu de nombreuses années pour réaliser que ce n'était pas une question de code, mais bien de jeu que vous livrez à la fin.

N'écrivez pas un système de composants de jeu élégant, sautez complètement l'éditeur et cédez l'état à l'aide de code, évitez les analyses auto-analytiques basées sur les données, la folie XML, et codez simplement ce qui est fichu.

... Il suffit d'afficher des choses à l'écran aussi rapidement que possible.

Et n'utilisez jamais l'argument suivant: «Si nous prenons un peu plus de temps et le faisons correctement, nous pouvons le réutiliser dans le jeu». DÉJÀ.

Est-ce parce que les jeux sont (principalement) visuellement orientés, il est donc logique que le code ait une importance particulière dans la vue; par conséquent, le fait de transférer des éléments dans des modèles / contrôleurs est assez minime, alors pourquoi s'en préoccuper?

J'ai entendu l'argument selon lequel MVC introduit une surcharge de performances, mais cela me semble être une optimisation prématurée et qu'il y aurait des problèmes de performance plus importants à résoudre avant de vous inquiéter des surcoûts de MVC (par exemple, pipeline de rendu, algorithmes d'intelligence artificielle, structures de données). traversée, etc).

Même chose pour le TDD. Je ne vois pas souvent de jeux utilisant des cas de test, mais peut-être est-ce dû aux problèmes de conception ci-dessus (vues mixtes / métier) et au fait qu'il est difficile de tester des composants visuels, ou des composants qui reposent sur des résultats probabilistes (par exemple, opérer dans des simulations physiques )

Peut-être que je ne fais que regarder le mauvais code source, mais pourquoi ne voyons-nous pas davantage de ces pratiques «d'entreprise» dans la conception de jeux? Les exigences des jeux sont-elles vraiment différentes, ou s'agit-il d'un problème de personnes / de culture (les développeurs de jeux viennent d'un contexte différent et ont donc des habitudes de codage différentes)?

Comme le dit la citation, de nombreux programmeurs commettent l'erreur de (tenter de) construire un système, pas un jeu. Généralement, ce système continue à devenir incontrôlable jusqu’à ce qu’il soit si complexe qu’il puisse théoriquement tout gérer, mais en pratique, tout ce que vous avez est un gros paquet de code. Ou plus souvent, avant même d'arriver à une phase de travail, vous êtes tellement empêtré dans un code qui ne court pas que vous perdez votre concentration (si vous en aviez au début) et votre motivation (puisque rien ne fonctionne vraiment).

Les prototypes et les itérations ont tendance à fonctionner beaucoup mieux. En fin de compte, un beau design peut en sortir, mais le plus souvent, quelque chose de plus simple et raffiné en sort. KISS et YAGNI viennent à l'esprit.

Personnellement, je pense qu’il faut un équilibre. S'il y a un mécanisme de base de votre jeu, travaillez dessus. Vous devez toujours itérer, mais vous devez l'affiner. Astuce: l'organisation de votre code n'est pas une mécanique essentielle de votre jeu.

Exemple : Peggle , de PopCap Games. La physique de la balle est un élément essentiel du jeu. Ils l'ont perfectionné! Je suis sûr qu'ils ont passé beaucoup de temps à s'assurer que c'était absolument parfait, parce que c'est ce qui fait le jeu. Mais en même temps, je peux totalement imaginer un premier prototype de leur jeu qui dessine peut-être simplement des images-objets à l'écran et effectue une sorte de détection de collision plus primitive et de rebondissements, juste pour voir si l'idée du jeu est amusante. Puis, une fois qu'ils ont découvert que tirer une balle et la regarder rebondir pouvaient être amusants, ils ont affiné le rebond de la balle. _{(ce ne sont que des spéculations, bien sûr)}

Cela dépend également de vos exigences techniques, que vous devez définir très tôt (pas votre conception de jeu, mais uniquement les exigences techniques). La plate-forme sur laquelle votre jeu fonctionne ne devrait pas changer, ou si vous pouviez le faire, vous devez savoir exactement dans quelle mesure vous envisagez de lui permettre de changer, ni plus ni moins. Concevoir sur cela. Si vous développez un jeu pour OpenGL et que vous vous moquez de DirectX, alors, ne vous en souciez pas. Cela signifie que s'il est plus pratique pour chaque entité de se dessiner toute seule et de ne pas s'inquiéter des usines ou d'autres modèles de conception similaires, faites-le. C'est bon, parce que cela répond aux exigences. Vous ne devriez pas avoir à le changer plus tard, malgré ce que vous vous dites. Et vraiment, pire scénario? Refactor plus tard., obtenir un jeu qui fonctionne sur une plate-forme même si cela signifie qu’il ne peut pas fonctionner simultanément et automatiquement sur votre grille-pain.

La conception pilotée par les tests est toutefois un sujet plus discutable. Je suis convaincu que les développeurs de jeux devraient en faire plus. Je pense aussi que les développeurs de jeux ont des horaires parmi les plus rigoureux et serrés, et ils pensent qu’ils ne peuvent pas se permettre de passer du temps sur TDD quand ils veulent juste lancer un jeu. Aussi, toujours avec la motivation, TDD est beaucoup plus lent et vous obtenez de voir beaucoup moins un jeu qui fonctionne (au moins au début). Cela peut avoir de graves effets négatifs sur la motivation du programmeur.

Je pense que c'est aussi juste un manque général de connaissances et de pratique. Je ne pense pas que le TDD soit répandu dans d'autres domaines non plus, mais comme le développement agile, je pense qu'il se répand. Vous pourriez dire que c'est en avance sur son temps (ou peut-être pas, comme le cas peut être des années à partir de maintenant). Plus important que TDD est "RDD" - Development Driven Development. _{Je viens d'inventer ça.}Quel est ton but? Faire un jeu. Tout le reste vient en second. Si vous pouvez prouver que TDD augmente la productivité et aide les équipes à respecter les délais, ne croyez-vous pas que tout le monde l'utilisera? Et peut-être que c'est le cas. Mais pour le moment, notre industrie est plus compétitive que jamais, il existe des délais plus difficiles et plus rapides, et tout doit fonctionner. Les ouvriers du bâtiment ne construisent pas d’abord des échafaudages; ils jettent les fondations, puis élèvent des murs et des sols, puis construisent des morceaux sélectifs d’échafaudages pour des tâches spécifiques qu’ils rendent plus pratique. Je pense que la même chose s'applique au développement de logiciels.

Désolé pour un si long post. J'espère que vous en avez tiré des enseignements. Je ne suis qu’un étudiant, parlant de mes observations, avec une expérience très limitée de l’industrie mais beaucoup de lectures d’experts de l’industrie. Alors prenez mes mots avec un grain de sel.

Et hé, faites ce que vous pensez qui fonctionnera. Vous pouvez toujours le changer ou le supprimer et recommencer. C'est la bonne chose à propos de toute forme d'ingénierie; Si au début vous ne réussissez pas, essayez quelque chose de différent. (ou quelque chose comme ça :-P) Vous ne coulez pas de béton; le logiciel est malléable.

En passant, je pose ce même type de question et je fais des recherches sur ces types de principes de conception depuis un certain temps. Voici quelques questions, à la fois ici et dans Stack Overflow, que vous pourriez trouver pertinentes:

• "Comment pouvez-vous organiser le code d'un jeu pour qu'il corresponde au modèle MVC?"
• "Comment concevoir un logiciel de jeu tel qu'il soit facile à tester à l'unité?"
• "Conception de moteur de jeu à base de composants"
• "De bons tutoriels ou ressources pour apprendre à concevoir un" framework "de jeu évolutif et basé sur des" composants "?"
• "Séparation de la logique de jeu et de rendu"
• "Les tests unitaires sont-ils viables dans la programmation de jeux?"
• "Le modèle de conception MVC est-il utilisé dans les jeux informatiques commerciaux"
• "Le développement piloté par les tests est-il une approche normale du développement de jeux?"
• "Est-ce que l'un de vous utilise Scrum pour le développement de jeux?"
• "Architecture pour le jeu - couple ou ne pas couple?"
• "Question de conception de jeu OO"

Voici ma réponse initiale à une question similaire sur SO de tout à l'heure, du moins en ce qui concerne la partie MVC de votre question:

Il est rarement utilisé dans les jeux. Il m'a fallu un certain temps pour comprendre pourquoi, mais voici ce que je pense:

MVC existe pour faire la distinction entre deux représentations. Le modèle est la représentation abstraite de vos données. C'est la façon dont la machine voit l'état de votre application. La vue (et les contrôleurs) représente une instanciation visible plus concrète de ce système d’une manière qui ait un sens pour les humains.

Dans la plupart des applications professionnelles, ces deux mondes sont très différents. Par exemple, le modèle d'un tableur est simplement une grille 2D de valeurs. Il n'est pas nécessaire de penser à la largeur des cellules en pixels, à l'emplacement des barres de défilement, etc. En même temps, la vue Feuille de calcul ne sait pas comment les valeurs des cellules sont calculées ou stockées.

Dans un jeu, ces deux mondes sont beaucoup plus proches l'un de l'autre. Le monde du jeu (modèle) est généralement un ensemble d’entités positionnées dans un espace virtuel. La vue du jeu est également un ensemble d’entités positionnées dans un espace virtuel. Les volumes, l’animation, la position, etc., tout ce que vous considérez comme faisant partie de la "vue" est également utilisé directement par le "modèle": l’animation peut affecter la physique et l’intelligence artificielle, etc.

Le résultat final est que la ligne entre le modèle et la vue dans un jeu serait arbitraire et inutile: vous finiriez par dupliquer beaucoup d’états entre eux.

Au lieu de cela, les jeux ont tendance à découpler les éléments le long des limites du domaine: intelligence artificielle, physique, audio, rendu, etc. seront aussi séparés que possible.

Parce que MVC ne rentre pas dans l'architecture d'un jeu. Le flux de données d'un jeu est totalement différent de celui d'une application enterprice, car il ne s'agit pas d'un événement et qu'il existe souvent un budget (très) serré en millisecondes pour effectuer ces opérations. Il faut beaucoup de choses en 16,6 millisecondes, il est donc plus avantageux de disposer d'un pipeline de données «fixe» et rigide qui traite les données dont vous avez besoin à l'écran exactement à cette heure.

De plus, la séparation est là; la plupart du temps, il n'est tout simplement pas câblé de la même manière que le modèle MVC. Il existe un moteur de rendu (View), la gestion des entrées utilisateur (Controller) et le reste, tels que la logique de jeu, la ma et la physique (Modèle). Pensez-y; Si vous récupérez les entrées utilisateur, exécutez l'ia et restituez l'image 60 fois par seconde, pourquoi auriez-vous besoin d'un observateur entre le modèle et la vue pour vous informer de ce qui a changé? N'interprétez pas ceci comme si je disais que vous n'avez pas besoin du motif Observer dans les jeux, mais dans ce cas, vous n'en avez vraiment pas besoin. Vous faites tout ce travail, chaque image, de toute façon.

Bien que TDD ne soit pratiquement jamais utilisé dans les studios de développement, nous utilisons des pratiques Agiles pour le développement de logiciels et SCRUM semble être le choix le plus populaire, du moins ici en Europe. La raison est simple, les changements viennent de partout. Les artistes voudront peut-être plus de budgets de texture, de plus grands mondes, plus d'arbres, tandis que les concepteurs voudront une histoire plus riche (plus de contenu sur disque), un monde de streaming et les éditeurs vous demanderont de finir dans les temps et les budgets, de même que le département marketing. Et en dehors de cela, "l'état de l'art" continue à changer rapidement.

Cela ne veut pas dire que nous ne faisons pas de tests non plus. La plupart des studios disposent de grands départements de questions-réponses, effectuent de nombreux tests de régression et effectuent régulièrement des tests unitaires. Cependant, il est pratiquement inutile de faire des tests unitaires au début, car une grande partie des bogues sont liés à l’art / aux graphiques (trous dans les maillages de collision, textures erronées, défauts dans la profondeur de champ) que les tests unitaires ne peuvent pas couvrir. Et en plus du code de travail, le facteur le plus important de tout jeu est que c'est amusant, et aucune unité ne le teste.

Rappelez-vous également que dans le monde de la console, cela est encore différent, car vous programmez davantage pour le matériel que pour toute autre chose. Cela signifie généralement (PS2 / PS3) que le flux des données est beaucoup plus important que le flux du code dans presque tous les cas; en raison de considérations de performance. Ce qui annule l'utilisation de TDD en tant qu'outil architectural dans la plupart des cas. Un bon code POO a généralement un mauvais flux de données, ce qui rend difficile la vectorisation et la parallélisation.

Pourquoi MVC et TDD ne sont-ils pas davantage employés dans l'architecture de jeu?

Attention: avis à venir.

MVC n'est pas utilisé (beaucoup) parce que:

1. MVC est une approche relativement nouvelle et les jeux sont généralement construits sur un ancien code. La plupart des personnes qui créent des applications MVC les construisent à partir de rien à chaque fois. (Je sais que MVC elle-même date de plusieurs décennies; ce qui est nouveau, c’est l’intérêt général suscité par ce logiciel, qui provenait essentiellement d’applications Web comme RoR). Dans le logiciel commercial sur lequel je travaillais était basé sur du code hérité, MVC n’était pas utile non plus. C'est une affaire de culture, mais ce n'est pas spécifique à un jeu.
2. MVC est essentiellement un modèle d'interface graphique pour les programmes événementiels. Les jeux ne sont ni dominés par les interfaces graphiques ni par les événements. Par conséquent, l'applicabilité n'est pas aussi grande que pour les applications Web ou autres applications basées sur des formulaires. MVC est généralement le modèle Observer avec des rôles bien connus, et les jeux n'ont souvent pas le luxe d'attendre d'observer quelque chose d'intéressant - ils doivent mettre à jour chaque image (ou une variation de celle-ci), que quelqu'un ait cliqué ou non. .

Cela ne veut pas dire que les jeux ne peuvent pas apprendre beaucoup de MVC. J'essaie toujours de séparer le modèle de la vue dans les jeux que je crée. L'idée traditionnelle selon laquelle la vue et le contrôleur étant deux parties du même objet (widget) ne fonctionne pas vraiment, vous devez donc être un peu plus abstrait à ce sujet. Je conviens avec vous qu'il est peu probable que la performance pose problème ici. Si quelque chose de performant peut tirer profit de la séparation des éléments visuels et des éléments logiques, cela facilite la cohérence du cache, le parallélisme, etc.

Le TDD n'est pas utilisé (beaucoup) parce que:

1. C'est vraiment difficile à utiliser dans les jeux. Encore une fois, c’est bien pour les logiciels événementiels où les entrées et les sorties sortent et où vous pouvez comparer ce que vous avez vu avec ce que vous attendiez et le cocher comme correct. Pour les simulations avec de grandes quantités d'état partagé, c'est beaucoup plus gênant.
2. Il n'y a aucune preuve indiscutable que cela aide quelque chose du tout. Juste beaucoup de réclamations, et quelques chiffres souvent basés sur des auto-déclarations et des appels à l'autorité. Peut-être cela aide-t-il les médiateurs pauvres à devenir médiocres, mais retient les bons programmeurs. Peut-être que le temps passé à écrire des tests pourrait être mieux dépensé pour apprendre les principes SOLID, ou pour concevoir l'interface correcte en premier lieu. Peut-être que donner des tests qui passent sans aucune preuve réelle que vous avez suffisamment de tests pour vous assurer que votre objet fonctionne correctement donne un faux sentiment de sécurité.

Encore une fois, à titre d'avertissement, je pense que les tests unitaires sont excellents, mais je ne pense pas que "test en premier" soit bénéfique ou raisonnable. Je ne pense pas non plus qu'il soit pratique de tester la simulation principale lorsqu'il y a tant de changements d'état partagé qui changent plusieurs fois par seconde. Je limite mes tests à mon niveau bas et à mon code de bibliothèque, en général.

Cependant, comme vous pouvez probablement le deviner, je suis largement contre les "pratiques de codage" des entreprises, car les entreprises sont bien connues pour leur dépassement des délais et des budgets. "Les développeurs de jeux aussi!" Je vous entends dire - eh bien, oui. Je ne pense pas que quiconque sache vraiment quel est le meilleur moyen de développer des logiciels pour le moment et je ne suis pas convaincu que l’adoption de pratiques imposées dans les logiciels grand public soit un pas en avant par rapport aux pratiques plus libres dans les logiciels de divertissement. En fait, je soupçonne que cela profite en premier lieu à ceux qui comptent sur les programmeurs Java de base, où ces approches ne constituent pas une échelle permettant de gravir de plus grandes hauteurs, mais un filet de sécurité pour les empêcher de tomber trop bas.

Comme le note Kylotan, "Dans les jeux, vous ne pouvez pas traiter l'aspect de la présentation comme un concept amovible et remplaçable, comme HTML et CSS pour les applications Web". Après avoir construit quelques jeux en utilisant un modèle MVC simple (pas un cadre énorme), j'ai constaté que le problème majeur est que votre modèle a besoin de connaître votre point de vue. Il est très probable que vous deviez utiliser des données bitmap de sprite, des données de hitbox ou des données de géométrie 3D de vos ressources artistiques pour vous aider à gérer la détection de collision (ou une autre tâche similaire). Cela signifie que chaque modèle a besoin d'une référence à sa vue, ce qui rompt le modèle MVC classique. Par exemple, vous ne pouvez plus créer une nouvelle vue sur un modèle existant, etc.

Le modèle de composant que vous voyez dans Unity3D, par exemple, est le meilleur moyen d’organiser le code de jeu.

MVC, à certains niveaux, est déjà utilisé dans le développement de jeux. Il est forcé par le système d'exploitation, qui a différentes interfaces pour l'entrée et les graphiques. La plupart des jeux contiennent également quelques instances supplémentaires de MVC, séparant par exemple la physique et les fils de rendu et d'entrée. Cela fonctionne bien. L'idée moderne de MVC semble être qu'il devrait être répété de manière fractionnelle jusqu'à ce que personne ne puisse plus comprendre le code. Les jeux ne font pas ça, heureusement.

TDD n'est pas utilisé car il est rarement connu qu'un jeu est "censé le faire" avant de parcourir plusieurs fois un prototype. Les pratiques de TDD, telles que les tests continus ou les tests d'intégration, sont souvent utilisées dans le développement de jeux.

Les systèmes de jeu évoluent lentement vers de meilleures pratiques. Les frameworks tels que XNA permettent de rendre le code plus généralisé / propre, sans alourdir le temps de conception ou d'exécution. Mais en général, je dirais que les systèmes de jeu ont tous pour objectif d'optimiser la complexité par rapport à la vitesse d'exécution, tout en respectant un calendrier de développement serré et en restant motivés. L'application de concepts de génie logiciel et de la conception de systèmes n'est tout simplement pas la priorité n ° 1 dans un tel environnement.

Dans mes projets de jeu personnels, j'essaie de commenter le code ou au moins de le rendre lisible, et jette ensemble des systèmes qui permettront un peu plus de flexibilité par la suite (c'est-à-dire la généralité) autant que possible, mais en fin de journée, si vous n'avez pas avancé votre jeu, il ne se sent pas très bien.

Aussi, généralement, à la fin de votre jeu, vous avez au moins 1000 idées sur la façon d’améliorer les mécanismes sous-jacents, les systèmes centraux, etc., de telle sorte que très peu de ce code "réutilisable" vraiment être utilisable. De jour en jour, je travaille dans le SE, et même si les systèmes sur lesquels nous travaillons peuvent être énormes, je pense honnêtement qu’ils sont dérisoires comparés à la complexité des jeux.

Je n'ai pas d'opinion particulière sur MVC en dehors du fait que la vue est souvent séparée de la logique par le simple fait que la boucle de rendu empaquette un tas de choses à traiter par certains matériels et que ce n'est pas l'endroit où vous voulez "jeu" logique "se passe en même temps. Le "contrôleur" est également séparé par le matériel, mais malheureusement, la plupart, sinon la plupart des développeurs de jeux, effectuent un travail "intéressant" dans le gestionnaire du contrôleur. (IMO, le gestionnaire du contrôleur devrait lire les boutons et les bâtons et créer une "présentation" à afficher par le jeu, mais ma tribune n'est pas très puissante.)

TDD, d’autre part, c’est quelque chose sur lequel j’ai une très forte opinion. Cela modifie simplement le développement de manière à produire un logiciel plus facile à utiliser. C'est plus difficile à faire, sans aucun doute. Bien sûr, comme c'est plus difficile à faire, ce n'est pas fait. Certaines personnes se plaignent du fait que TDD (ou plus généralement les tests unitaires) n’a aucune valeur parce que "le jeu est le test", mais le fait est que, dans TDD, le test n’est presque pas pertinent. Le point clé de TDD est la conception logicielle et l’architecture qui découle du processus.

Embrasser TDD change vraiment l'approche de la programmation. J'avais des sentiments sur ce qui était bien et ce qui était faux avant de me lancer dans la voie du TDD, mais une fois que j'ai sauté dans les pieds, j'ai vraiment compris beaucoup plus en quoi mon travail aidait ou entravait mon développement futur. . En effet, c’est en quelque sorte le point derrière le post de la salle des douanes, TDD sans le t .

Pour en revenir à la raison pour laquelle il n'est pas davantage utilisé dans les jeux, au-delà de la dureté, les gens se rendent compte que la manière dont ils l'ont toujours fait par le passé rendait leur travail plus dur, et que les programmeurs, en particulier, avaient du mal à regarder, beaucoup moins avaler.

Je suis convaincu que les personnes qui refusent d'accepter TDD ne veulent tout simplement pas être de meilleurs programmeurs. Ils pensent déjà qu'ils sont «excellents» en programmation, en conception ou en architecture, alors qu'en fait leur code dit quelque chose de complètement différent.