How would MVVM be for games?

Question

Particularly for 2d games, and particularly silverlight/wpf games.

If you think about it, you can divide a game object into its view (the graphic on the screen) and a view-model/model (the state, ai, and other data for the object). In silverlight, it seems common to make each object a user control, putting the model and view into a single object. I suppose the advantage of this is simplicity. But, perhaps it's less clean or has some disadvantages in terms of the underlying "game engine".

What are your thoughts on this matter? What are some advantages and disadvantages of using the MVVM pattern for game development? How about performance? All thoughts are welcome.

Answer 1

In a word - great!

In fact, Josh Smith just published a book on MVVM using a game as his explanatory app. Recommend you read Ward Bell's excellent (and free) critique of Josh's work first.

HTH,
Berryl

Answer 2

You may run into performance problems, since MVVM typically leads to a lot of Data Binding functionality in WPF to accomplish a clean separation. However, it's still an excellent idea and worth pursuing; you can always profile the application later and optimize certain elements, if you need to. Most likely it'll be the AI that's gating rather than the UI integration.

As far as figuring out where to divide Model | View Model | View, I like to take the following approach:

1. The Model is everything that has nothing or very little to do with direct user interaction. This would include the game rules engine, the AI, etc. The View Models interact with the Model in well-defined ways where the user either has control or receives feedback on what's happening in the Game Model.

2. I try to create View Models for each major component of the interface. For example, if you were building an RPG, you might have an InventoryViewModel, CharacterStatsViewModel, WorldMapViewModel, etc. I usually don't create them for individual controls/widgets (like health indicators, item glyphs or '+' signs to level up) unless they have a reasonably complex interface.

3. The Views are of course how the user finally gets to interact and observe, which is fairly straightforward to understand. One nice thing is that you can create multiple Views for a given ViewModel, so you might have a large view for the Inventory and also a smaller view for quick access to important items, for example, if the way you interact with them is essentially the same.