Design Question

[delt0r]

Yesterday I went through a lot of my code to see how strictly I do follow MVC. To my surprise I stick to the strict definition every time. Well ok the controller is often an inner class to the view. Its wasn’t my discipline of adhering to patterns that did this. Its the fact that i want my models to be clean. Change notification is generally done with a call back. But often I “make” the view poll for changes. but the view does query the model often, as per the picture.

My game is the same. I have a game model that knows nothing about rendering or opengl at all. It can be queried by the view to determine what to draw.

However i often have a lot of model logic in my models. I am not really a fan of data only objects per say. But this does not invalidate the MVC … it would if i had view dependent logic in the model.

[Demonpants]

@delt0r

Yesterday I went through a lot of my code to see how strictly I do follow MVC. To my surprise I stick to the strict definition every time. Well ok the controller is often an inner class to the view. Its wasn’t my discipline of adhering to patterns that did this. Its the fact that i want my models to be clean. Change notification is generally done with a call back. But often I “make” the view poll for changes. but the view does query the model often, as per the picture.

My game is the same. I have a game model that knows nothing about rendering or opengl at all. It can be queried by the view to determine what to draw.

However i often have a lot of model logic in my models. I am not really a fan of data only objects per say. But this does not invalidate the MVC … it would if i had view dependent logic in the model.

So you would never do this:

public class Entity
{
    public void update()
    {
        //Do logic stuff
    }

    public void draw()
    {
        SpriteManager.getSprite(mySpriteName).draw(x, y, width, height);
    }
}

public class View()
{
    public void draw()
    {
        for (int i = 0; i < model.getEntities().size(); i++)
        {
            model.getEntities().get(i).draw();
        }
    }
}

public class Model()
{
    public void update()
    {
        for (int i = 0; i < getEntities().size(); i++)
        {
            getEntities().get(i).update();
        }
    }
}

I end up having both the rendering and the logic update code within the Entity object, but the Model never calls draw() and the View never calls update(). Do you do something like have some other class do the Sprite draw call, and maybe get the sprite name, position, etc. from the Entity with accessors?

[delt0r]

No I would not. In my case Entity is part of the model (the model is a “entity” collection). The controller in my case is either a AI bot (called a borgatron --cus bot is boring), a “network” controller, or a “gui” controller.

The view would querry (in a thread safe manner) the model about, the list of entitys. This list is just data. ie postions, and type. The view know how to get a 3d model from the type, then draws it at x,y,z. It does not delegate drawing to the entity.

Now if i run a dedicated server I don’t need any of the opengl data at all. I can plug in borgs or network players at will and there is just lots of general goodness.

My implementation is more complicated in reality. But not as far as MVC goes. I just do things like interpolate entity states for smooth animation, and a way to decouple game turns from animation frames.

[Demonpants]

That’s a very clear and useful way of putting it, thanks. And yeah, if you’re looking to have AI / networked / local control options, that is absolutely the best way of doing things. I will definitely borrow some of these concepts in the future. Typically for AIs I was making a subclass of Entity and overriding the update() method with AI choices. Definitely some big disadvantages to this, obviously.

[cylab]

@cylab

In strict MVC you would move the model.update() stuff to controller.update(), so that the model doesn’t have any logic in it. It just stores the games state for the current timestep and maybe knows how to load and save itself

@Eli Delventhal

As for putting all game logic in a Controller… I suppose that means that the game loop and the like are in the controller, and they update everything? That seems like it’s also a pain in games, because I like having an update() function in every Entity where it knows how to update itself.

I have to correct myself here. This is only true, if you only consider your game state the model. But you can “model” anything you want. Data structures, behaviour, physics etc. So if you want your Model to also contain behaviour information, its OK to implement like you did.

You might want to separate behaviour from your Entities in some kind of “Behaviour (Sub)model” to reuse behaviour schemes for multiple Entities, though. Those are however not used from the View but usually applied to the Entities directly, so they might not fall into consideration when talking about MVC.

@Eli Delventhal

I don’t think it makes too much sense to have the model notifying of the view of changes via a listener is because in a game setup you will typically have separate timing for rendering and updating - therefore it makes more sense for the view to pull the current state from the model whenever it happens to be rendering.

I also don’t think that asynchronous change notification is the essential ingredient to make a design an MVC implementation. A View can (and does) render a Model for various reasons and not only on change notification. So driving the rendering from the game loop does not break any MVC paradigma.