Compartimentation de type MVC dans les jeux? [fermé]

J'envisageais la conception d'un jeu (traduire un jeu de société sur l'ordinateur en particulier, ce qui, je suppose, est pertinent dans ce cas) et il m'est venu à l'esprit qu'il pourrait être judicieux de construire le `` jeu '' séparément de `` l'écran ''.

Cela me permettrait de prototyper quelque chose rapidement avec une interface de texte simple, puis de le remonter plus tard. Cela me permettrait également de porter le jeu sur d'autres médias plus facilement.

Ce type de compartimentation est-il courant dans les jeux? Dois-je essayer de décomposer davantage les choses? Y a-t-il des complications que je pourrais manquer?

Un jeu de société est un bon exemple de jeu qui pourrait être créé à l'aide de MVC, car la logique de jeu (modèle) existe indépendamment des visuels (vue). Cependant, si vous envisagez un jeu d'action comme Gears of War, la géométrie des modèles 3D est intrinsèque à la logique du jeu, donc séparer la vue comme si elle était interchangeable devient inutile. Unity3D est un excellent exemple d'une manière plus spécifique au jeu d'organiser le code. Vous avez une classe d'entité de base à laquelle vous ajoutez des fonctionnalités avec des composants, où un composant peut gérer le dessin de l'entité, un gérer la logique de jeu, etc. Consultez ces célèbres articles de blog sur le sujet:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://gameprogrammingpatterns.com/component.html

Mon point de vue:

• Le modèle est l'endroit où se trouvent la plupart des données et toute la logique a lieu.
  Il lit une file d'attente d'événements d'entrée et modifie l'état du jeu en conséquence.
  Il traite ensuite des choses comme la physique et d'autres composants de base qui mettent également à jour l'état du jeu.
  Boucle. C'est tout.
  Le but est de rendre le modèle indépendant: il ne dépend pas de la vue ou des trucs du contrôleur: vous devriez être capable de faire un programme qui n'exécute qu'un modèle.
• La vue lit simplement l'état du jeu du modèle, met à jour ses propres composants dédiés à la représentation des données et affiche les choses à l'écran.
  Il n'écrit jamais rien sur le modèle, c'est un processus en lecture seule, sauf peut-être l'enregistrement d'un gestionnaire d'événements (comme "Hey Mister Model, lorsque vous détectez une collision entre ces deux objets, veuillez appeler mon gestionnaire d'événements qui émet un son! ").
• Le contrôleur intercepte les événements d'entrée et les transmet à la file d'attente d'entrée du modèle. Il lit la vue (ce clic de bouton s'est-il produit sur un bouton d'interface utilisateur?).

De cette façon, vous pouvez brancher un faux contrôleur qui lit un fichier contenant des événements d'entrée préenregistrés.
Faites également une vue simple qui enregistre simplement les choses dans un fichier.
Très utile pour tester et déboguer.

N'oubliez pas de faire la mise à jour du modèle à un rythme constant (pas de temps fixe), et la vue et le contrôleur aussi vite que possible (mais pas trop de variables).

Ce type de compartimentation est la séparation entre un moteur et un code de jeu, et est assez courant. Il y a beaucoup de place pour l'abstraction en cours de route.

Votre moteur et les données graphiques spécifiques à vos jeux pourraient être la vue, votre code de jeu le modèle et le contrôleur serait la colle que vous utilisez pour indiquer à votre moteur quelle texture appliquer à quelle entité dans votre code de jeu.