Gluing Model and View Data Together But Separating Concerns

Question

I've built a couple of 2D games that are roughly MVC; that is, the main game data and logic are separated into the model (and possibly controllers), and I have a bunch of screens/states that just pull stuff from the model class and draw that on screen.

This is not a complete separation, because things like size, collision detection, etc. tend to be view concerns and not model concerns.

In any case, I have a difficult time "gluing" together models and views. Is there a good way to do this, while still preserving the separation of concerns?

Let's say I'm working with a Sprite class to represent an image, and I have a Player class representing my player (X, Y, number of lives, running/walking, etc.). How do I associate them together?

For example, Player can be a subclass of Sprite, or can contain an instance of Sprite (or vice-versa), or I can have a third class (PlayerModelView) that contains an instance of both Player and Sprite, or something else entirely.

(I've tried the latter approach, but it usually ends with a lot of type conversions and the model checking with the view about collisions.)

Answer 1

When doing MVC-style architecture (not just in gaming!) it can be helpful to remember that there is often more than one model. Besides the (usually) obvious model of the Player's state (his position, life, and so on), there may be models (dependant on language and engine) for Sprite, or other 'display' classes.

For instance in Valve's Source engine, the 3-dimensional art (and animations) are encapsulated in their own files (representing the mesh, current animation, a few other things, but not the object's position), and have absolutely no relation to an entity's data (which contains position, orientation, and so on).

Because the two models usually don't (or aren't supposed to) have much to do with each other, they can (or possibly should) be wired together with seperate controllers: One for Player model to Sprite model updates (setting the currently playing animation, display position, etc), and one from the Sprite (for what, and where relative to other display elements) model to the view.

Here's a quick (Java-based Psuedo-code) example with attributes:

public Beast {
    private String name;
    private List<Behaviour> behaviours;  
}

public Player {
    private List<Beast> paddock;
    private List<Beast> leashed;
    private List<Beast> hospital;

public BeastAnimation { // One per beast!
    private Map<Behaviour, Animation> animations;
    private Animation current;
}

With these entities, you'd want a controller that would set the BeastAnimation's current based on whatever Behaviour was being executed - depending on game type, you usually need to start the animation even if the object is otherwise not (at least initially) visible, you don't want the entity doing nothing the first time he's seen (especially if the animation is long). Please note that this doesn't necessarily mean rendering the animations or (depending on display type) even applying transforms.
You're also going to want a controller that takes the 'current' BeastAnimation when actually rendering out the animation. Please note that the various animations only their relative positions, and shouldn't really know where the camera is - this controller acts as the necessary translation bridge. It's good to note that a fair number of graphics engines essentially take care of this for you - you only have to hand it the necessary models/animations, and say where the camera is - they're a controller/view package in one. Otherwise, how (and what the necessary translations are) varies by case