# Gluing Model and View Data Together But Separating Concerns

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.)

• And this is why MVC doesn't really work for game development... Dec 6 '11 at 19:32
• Sprite holds image data and therefore should be part of your model. Dec 6 '11 at 19:49
• Potentially (dependant on language and engine), you have two models - one for the Player's state (position, lives, and so on), and one for the Sprite state (frame, image offset, etc). The two models don't really have much to do with each other; wire them together with a controller as normal, and wire a controller for the Sprite-model to view translation. Dec 6 '11 at 21:21
• I understand the value of unit testing in games, like being able to run checks against your game logic, and, to a less thorough extent, physics and collision. But wouldn't it be just as easy with any sort of logic and rendering separation? I've been playing with the entity component design used in Artemis, and since it's comprised of strictly data (Components) and logic (Systems), you can unit test the Systems and ensure the Components have valid data. The view would effectively just be another controller albeit one you can't really write an automated test for (assuming use of a graphics lib). Dec 7 '11 at 5:31
• My point is keeping your view/display/render-oriented classes organized separated from your logic classes is not something exclusive to MVC. MVC may accomplish that, but MVC also carries impplementation style baggage with it. I feel like games I've worked on, even those with clearly separated display/logic/data layers rarely are able to cleanly fit their code modules into categories of model, view, controller, viewmodel, modelview, or whatever. I could see myself having to create a lot of redundant classes in order to fit the architecture pattern. Dec 7 '11 at 22:51

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> 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

• I'm in 2d, not 3d. So your solution is basically to create a class for the model (Beast), a class for the view (BeastAnimation), and a "glue" class to connect the two (Controller?) Dec 8 '11 at 2:44
• @ashes999 - BeastAnimation isn't a view - it's another model; specifically, one containing view-related data (so, a model of the view). If I've done the rest of the work right, I can change from 2d to 3d (or vice versa) simply by switching out the view and whatever the various Animations contain - no other part of my code has to change (supposing that gameplay doesn't change...). Every (non-trivial) view is going to be backed by models specifically for the view of some sort. This potentially includes text-based adventures... Dec 8 '11 at 16:51