MVC ou composants, ou les deux?

Je suis un développeur expérimenté, mais récemment, je souhaitais me lancer dans la programmation de jeux, mais comme vous le savez, le développement de jeux est une bête complètement différente de la plupart des autres formes de programmation (peut-être seulement mieux que le développement de systèmes d'exploitation).

Cela étant dit, j'ai lu Game Coding Complete (ISBN 978-1-58450-680-5) par Mike McShaffry.

À l'origine, j'allais essayer de développer avec un modèle de composant avec l'assortiment de composants habituels (par exemple SpacialComponent, VisualComponent, EntityLogicComponent, etc.) mais M. McShaffry recommande d'utiliser le modèle MVC qui a l'air très attrayant mais je ne sais pas comment je peut le faire fonctionner avec le modèle de composant si possible, mais, sans composants, le modèle MVC ressemble en quelque sorte au monstre diabolique de l'héritage monolithique et pas très flexible, ce qui ne m'intéresse pas vraiment.

Je ne sais vraiment pas où aller à partir de ce point.

Avez-vous des experts vaudous en codage de jeu plus expérimentés?

Merci beaucoup!

Questions utiles:

Architecture du moteur de jeu MVC (Model-View-Controller) - Oui ou Non?

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

Compartimentation de type MVC dans les jeux?

Pour moi, j'ai une classe de base RenderComponent, puis quelques-unes qui en héritent (GameSprite, UISprite, ou si vous faites 3d StaticModel, DynamicModel, BillboardModel, etc.) et si l'objet se veut rendu, l'objet soumet son Membre RenderComponent du système de rendu. Pas besoin que le système de rendu sache quel type d'objet a soumis le RenderComponent. Il sait juste qu'il a quelque chose à rendre et il vaut mieux le faire, sinon!

Gardez-le basique et centré sur la composition plutôt que sur l'héritage. La séparation de la logique, des données et de la représentation n'est pas incompatible avec un système de composants.

Je recommanderais d'ignorer les composants de votre premier jeu car ils résolvent certains types de complexité en ajoutant plus de complexité dans d'autres domaines, et si vous n'avez pas encore créé un jeu, vous n'avez aucune idée si ce compromis en vaut la peine ou non.

Pour la plupart cependant, ne vous enlisez pas dans les paradigmes de programmation et codez simplement un jeu. Il n'y a pas de bonne ou de mauvaise façon, sinon personne n'aurait à poser ce genre de question. Élaborez-le au fur et à mesure.

Je n'utiliserais pas un modèle MVC strict, mais je séparerais votre rendu de votre simulation et le collerais sur un autre thread.

Je pense que les composants sont très utiles en fait, mais je vois souvent des gens les ignorer et écrire leur code directement dans le composant "principal" quel qu'il soit. Vous devez vous rappeler que les jeux sont pleins de hacks car ils sont souvent écrits à une date limite en supposant que le code ne sera pas réutilisé.

Je suis un peu confus quant à la raison pour laquelle vous pensez que ces approches sont incompatibles. Quel code de jeu avez-vous regardé?

Personnellement, je pense que les jeux nécessitent une conception initiale. J'ai vu quelques bases de code qui étaient des cauchemars à cause de la "mentalité de juste coder".

Cela dit, je pense que vous devez simplement vous lancer et coder un jeu. Vous ferez tellement d'erreurs en écrivant votre premier jeu que ce genre de problèmes n'aura pas d'importance. Une fois que vous avez une meilleure compréhension de ce qui est requis, vous pouvez revenir en arrière et commencer à regarder l'architecture et voir comment elle résout les problèmes que vous avez rencontrés.