Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am using a retained mode renderer similar to the display lists in Flash. In other words, I have a scene graph data structure called the Stage to which I add the graphical primitives I would like to see rendered, such as images, animations, text. For simplicity I'll refer to them as Sprites.

Now I'm implementing an architecture which is becoming very similar to MVC, but I feel that that instead of having to create View classes, that the sprites already behave pretty much like Views (except for not being explicitly connected to the Model). And since the Model is only changed through the Controller, I could simply update the view together with the Model in the controller, as in the example below:

Example 1

class Controller
    Model model;
    Sprite view;
    void TeleportTo(Vector2 position) { model.Position = view.Position = position; }

The alternative, I think, would be to create View classes that wrap the sprites, make the model observable, and make the view react to changes on the model. This seems like a lot of extra work and boilerplate code, and I'm not seeing the benefits if I'm just going to have one view per controller.

Example 2

class Controller
    Model model;
    View view;
    void TeleportTo(Vector2 position) { model.Position = position; }

class View
    Model model;
    Sprite sprite;
    View() { model.PropertyChanged += UpdateView; }
    void UpdateView() { sprite.Position = model.Position; }

So, how is MVC or more specifically, the View, usually implemented when using a retained-mode renderer? And is there any reason why I shouldn't stick with example 1?

share|improve this question
up vote 3 down vote accepted

as I've recently written as answer to another question, I tried to adapt the MVC pattern to game entities. My advice is: forget it.

Have a look to a Entity based system to achieve data/graphic/logic uncoupling: Implementing features in an Entity System

however, if you really want to stick with the MVC pattern what I used to do is to inject the model both into the controller and the view. The view was then using the model to update itself (more or less like your second case)

share|improve this answer
+1 for Entity/Component. Its saving my a lot of code compared to my previous deep-hierarchy approach. – David Lively Sep 4 '12 at 16:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.