Architecture du moteur de jeu MVC (Model-View-Controller) - Oui ou non? [fermé]

Je lis un grand livre, Game Coding Complete , et ce livre recommande fortement d'utiliser l' approche MVC (Model-View-Controller) , avec trois couches clés:

1. Couche d'application de jeu
2. Game Logic
3. Vue du jeu

Pour moi, cette approche ressemble à une surpuissance pour un jeu sur ordinateur mobile.

Quelle est votre opinion, s'il vous plaît? Vaut-il la peine de mettre en œuvre cette architecture, même si elle ajoute une communication supplémentaire nécessaire entre les modules? Cette conception peut-elle consommer autant de puissance CPU, qu'à la fin, le résultat serait considérablement plus lent que s'il n'était pas implémenté?

Je supporte quelque peu l'utilisation d'une structure MVC même pour un jeu mobile simple. À tout le moins, cela résout un problème qui tourmente les développeurs qui ne se sont pas fait mordre assez souvent: séparer le code d'affichage de la logique du jeu.

Je dirai également, cependant, de garder à l'esprit que MVC, comme tous les modèles de conception, existe pour vous faciliter la vie . Cela signifie que si, à un moment donné, le respect de certaines règles concernant ce que vous devez et ne devez pas faire lorsque vous utilisez MVC vous rend la vie plus difficile, ignorez-la . Deux choses se produiront: 1) vous serez mordu plus tard, puis vous comprendrez pourquoi le faire différemment en premier lieu vous aurait en fait rendu la vie plus facile à long terme, ou 2) aucune conséquence.

La programmation informatique, de par sa nature, attire de nombreux adeptes des règles qui apprécient le respect du principe élégant plutôt que d'accomplir quoi que ce soit, et ils aiment proposer leur système de valeurs; ne les laissez pas faire de vous l'un d'eux. La chose la plus importante qui puisse arriver à votre jeu est de l' expédier .

Les conceptions de compilation ne consomment pas de puissance CPU, sauf si vous avez un compilateur incroyablement abyssal. Un langage ou une approche orientée objet n'est pas différent dans ses caractéristiques de performance d'un langage procédural. Vous n'invoquerez aucune surcharge supplémentaire pour l'utilisation de MVC. La modularité existe au moment de la compilation, pas à l'exécution, une fois que le code est en ligne et optimisé, cela ne fera aucune différence.

De nombreux jeux modernes exécutent en fait les modèles et les vues sur des threads séparés et bénéficient de grands avantages en termes de performances sur la plupart des plates-formes.

En fin de compte, MVC est une bonne conception qui vous offre une maintenance accrue et moins de bugs, etc. gratuitement . Il n'y a aucune raison de ne pas l'utiliser. C'est comme demander pourquoi vous devriez utiliser une forboucle au lieu de gotos manuscrits . À moins que vous n'ayez un design supérieur à l'esprit, c'est certainement mieux que rien.

Edit: les conceptions de compilation ne consomment pas de puissance CPU. Les conceptions d'exécution comme l'héritage le font évidemment.

Il y a presque toujours un compromis entre la clarté du code et les exigences techniques (vitesse, mémoire, etc.) du programme. Les langages orientés objet ont un surcoût par rapport aux langages procéduraux, mais ils se sont avérés avoir de nombreux avantages par rapport aux langages procéduraux, en particulier dans la maintenance à long terme du code (bogues, etc.) et souvent aussi la vitesse de développement.

Donc, avec cela à l'esprit, je propose que MVC mérite d'être implémenté pour vous en tant que programmeur de jeux . Votre code suivra mieux les principes orientés objet, en particulier l' encapsulation , et vous aurez probablement beaucoup plus de facilité à le maintenir (correction de bugs ou ajout de nouvelles fonctionnalités).

D'un autre côté, assurez-vous de terminer un jeu et de ne pas consacrer autant de temps au "moteur" qu'il ne sera jamais fait.

Pour plus d'informations, veuillez lire la question "Pourquoi MVC et TDD ne sont-ils pas davantage employés dans l'architecture de jeu?" et ma très longue réponse.