Comment MVVM serait-il pour les jeux?

Question

Particulièrement pour les jeux 2D, et en particulier les jeux Silverlight/WFP.

Si vous y pensez, vous pouvez diviser un objet de jeu dans sa vue (le graphique sur l'écran) et un modèle de vue/modèle (l'état, ai, et d'autres données pour l'objet). Dans Silverlight, il semble commun de faire de chaque objet un contrôle utilisateur, en plaçant le modèle et la vue dans un seul objet. Je suppose que l'avantage de ceci est la simplicité. Mais, peut-être est-il moins propre ou a quelques inconvénients en termes de "moteur de jeu" sous-jacent.

Que pensez-vous de ce sujet? Quels sont les avantages et les inconvénients de l'utilisation du modèle MVVM pour le développement de jeux? Que diriez-vous de performance? Toutes les pensées sont les bienvenues.

Answer 1

En un mot - génial! En fait, Josh Smith vient de publier un livre sur MVVM en utilisant un jeu comme application explicative. Je vous recommande de lire l'excellent (et gratuit) critique de Ward de l'œuvre de Josh en premier.

Answer 2

Vous pouvez rencontrer des problèmes de performances, car MVVM génère généralement beaucoup de fonctionnalités de liaison de données dans WPF pour réaliser une séparation nette. Cependant, c'est toujours une excellente idée et mérite d'être poursuivie; vous pouvez toujours profiler l'application plus tard et optimiser certains éléments, si nécessaire. Très probablement, ce sera l'IA qui gating plutôt que l'intégration de l'interface utilisateur.

Pour déterminer où diviser Modèle | Voir le modèle | Vue, j'aime prendre l'approche suivante:

1. Le modèle est tout ce qui n'a rien ou très peu à voir avec l'interaction directe de l'utilisateur. Cela inclut le moteur de règles du jeu, l'IA, etc. Les modèles de vue interagissent avec le modèle de manière bien définie, où l'utilisateur a le contrôle ou reçoit des commentaires sur ce qui se passe dans le modèle de jeu. Je tente de créer des modèles de vue pour chaque composant majeur de l'interface. Par exemple, si vous construisiez un RPG, vous pourriez avoir un InventoryViewModel, CharacterStatsViewModel, WorldMapViewModel, etc. Je ne les crée généralement pas pour des contrôles/widgets individuels (comme des indicateurs de santé, des glyphes d'éléments ou des signes '+') à moins qu'ils aient une interface raisonnablement complexe. Les Vues sont bien sûr la façon dont l'utilisateur peut enfin interagir et observer, ce qui est assez simple à comprendre. Une bonne chose est que vous pouvez créer plusieurs vues pour un ViewModel donné, ainsi vous pouvez avoir une vue large pour l'inventaire et aussi une plus petite vue pour un accès rapide aux éléments importants, par exemple, si vous interagissez avec eux même.