Model View Controller Architecture Issues

[SteveTheCoder]

I've been writing business software for a long time, but I am fairly new to games and I am still trying to get a feel for the architecture of things.

There are some obvious benefits in separating things out, but for games, Model View Controller (MVC) seems to be an overly complex pain to me.

For example. The world contains a lever and when that lever is pulled and locks into place, we want a lever sound to be played. We have some instance of a lever class in our world and when the user clicks the part of the screen corresponding to the lever, we update the world and tell it that the lever has been pulled.

Now, when we come to our view.update() method, we can see that the lever is in the "on" state, so we play the lever sound. Problem is though, because our view is separate from our model, knowing that the lever is on is not enough. A lever is going to be on for some time, and if we just have an "on" state, the view is going to read that and play the lever sound for every loop. So what do we do? We can complicate the model by having a "JustPulled" indicator on the lever in addition to the "on" state. We will of course then have to remember to clear the "JustPulled" flag on the next world update (an extra complication). An alternative is that from the model you could raise some kind of JustPulled event which is caught in the view, but that all seems quite out of sequence with the idea of updating the model, then displaying it.

e.g.

UpdateGame()
{
Word.update();
View.update();
}

It would be so much easier for the lever object to just play the sound itself. Yes, the model and view would be mixed, but separating them just seems to complicate things and result in more code and more state to manage. MVC seems to make a lot more sense in an event driven business app than it does in a game loop.

I can see similar issues popping up with many other game objects and MVC. But then I'm new games, so perhaps I'm not seeing things very clearly. Have people here had similar headaches with MVC?

[mzechner]

That's a common problem one runs into when using MVC for games. I usually "solve" it by introducing model classes that represent events. Those are short lived and might only survive a single model update cycle, but are enough to indicate to the view that e.g. a sound needs to be played. It's similar to an event mechanism really.

[SteveTheCoder]

Not sure I get you 100%.

I can imagine having an event object that the view contains. It has properties like .LeverWasJustPulled. The Model then also has a reference to this event object and can set .LeverWasJustPulled to true. The view can then act on this when it's update method is called. Something like this seems nicer than raising an event from the model, since the view is supposed to update in one big step when view.update is called, not in some piecemeal way with events being received from the model. I suppose what I have proposed is a cache of events which are handed to the view ready to be acted on when the view's update method is called.

[mzechner]

What i'm saynig is that you'd have a cache of events in your model. E.g. a "PlaySound" event. Each rendering cycle the view checks the model on those events and acts accordingly. The model will discard those events automatically in the next frame. They are one-off things that only live for a single cycle.

[wmdAndrew]

Hey Steve,

Coming from website development with MVP/MVC data patterns we went through this Over time this is what we have come up with:

Data Access tier:
Data Models
Data Access Repositories

Menu System:
Data Models
Listeners (controllers)
Screens (view)

Game Play:
Simulation Models (models)
Simulation (think controller inherits SimulationListener with event methods)
Render Models (meshes/animations)
Renderer (think View)

For games it's more like Simulation runs as fast as you can run it... Renderer renders at a set interval reading the simulation objects to determine what to render. It is less of a linear approach then say the menu system or other applications like websites.

Simulation models contain update methods to update the physics/states based on events. For example, in Capture the Flag our flag has dropped(), reset(Vector), captured(GameMech (simulation object)), and update(). The simulation models also contain pointers to objects. Our flag has a GameMech carrier object. The update() takes into account the carrier's position and updates the flags position.

Here is the scenario: Mech runs over flag -> fires simulation listener event flag picked up (GameMech) -> Flag object carrier set -> Mech dies fires mech killed event -> flag object dropped() method invoked in the mech killed event -> Mech from flag team runs over Flag -> fires flag returned event -> flag object reset() method invoked in the mech returned event

Now the renderer/View is dumb. It just renders the objects the simulation updates and when needed brings in meshes/animations for those objects. The only action the View has is raising events in the simulation. Like when a rocket button is pushed it raises the event of launching a missile. The simulation adds the missile and position of missile. Next time the renderer renders it then can see that object and just produces the mesh at that given location.

Hope that helps.

[SteveTheCoder]

As I'm writing my game though, I am wondering. Given all the extra complexity and often ambiguity over what should go in the model or view, are you really gaining that much with an MVC approach. Looking around it seems to cause a lot of headaches compared to the "dirty" intuitive approach of just having a .Draw method on your Game objects.

[Obli]

I'm a big fan of MVC/MVVm patterns, and apply them in all my games. At first I encountered some difficulties, but once you understand how to circumvent them, separation of concerns becomes a real advantage.

For your kind of problem, the solution I use everywhere (in games, business desktop guis, etc) is event-based logic. You model should truly be separated from everything else, and therefore it needs a way to yell "I updated this stuff, your turn now!" at any other part of the game that may need it (usually the view).
In your situation, you would need events for "leverPulled" and "levelReleased" actions for instance. Therefore, the view, by registering itself as an event listener, will know when it needs to update, and for how long...

Of course, being specialized in gui development helps the fact that I put events/callbacks everywhere, even in games :p

[felixwatts]

I agree with Obli, some things are inherently 'state' (lever position) and others are inherently 'event' (lever position changed). Your simulation should raise events which your view handles appropriately. When the 'lever position changed' event occurs your view should play a sound.

[mzechner]

+1 for events/message queues. The only downside is that debugging can become a bit harder if you go to crazy. I'd also have the controller send the events, not the model.