Model View Controller Architecture Issues

Anything about development not directly related to libgdx, e.g. OpenGL, Android APIs etc.

Model View Controller Architecture Issues

Postby SteveTheCoder » Sat Mar 24, 2012 1:27 am

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?
SteveTheCoder
 
Posts: 20
Joined: Sat Mar 24, 2012 12:45 am

Re: Model View Controller Architecture Issues

Postby mzechner » Sat Mar 24, 2012 2:14 am

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.
mzechner
Site Admin
 
Posts: 4709
Joined: Sat Jul 10, 2010 3:50 pm

Re: Model View Controller Architecture Issues

Postby SteveTheCoder » Sat Mar 24, 2012 5:09 pm

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.
SteveTheCoder
 
Posts: 20
Joined: Sat Mar 24, 2012 12:45 am

Re: Model View Controller Architecture Issues

Postby mzechner » Sun Mar 25, 2012 10:38 am

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.
mzechner
Site Admin
 
Posts: 4709
Joined: Sat Jul 10, 2010 3:50 pm

Re: Model View Controller Architecture Issues

Postby wmdAndrew » Sun Mar 25, 2012 5:37 pm

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.
Did you find my post helpful? If you want to help me in return please download and provide feedback for Scrap Metal Mech Feedback can be posted on our Scrap Metal Mech Show Case thread
wmdAndrew
 
Posts: 65
Joined: Tue Aug 23, 2011 11:55 pm

Re: Model View Controller Architecture Issues

Postby SteveTheCoder » Mon Mar 26, 2012 2:29 pm

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.
SteveTheCoder
 
Posts: 20
Joined: Sat Mar 24, 2012 12:45 am

Re: Model View Controller Architecture Issues

Postby Obli » Thu Apr 05, 2012 12:28 pm

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
Obli
 
Posts: 616
Joined: Mon Jan 10, 2011 6:18 pm
Location: Bordeaux, France

Re: Model View Controller Architecture Issues

Postby felixwatts » Wed Apr 11, 2012 9:39 am

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.
felixwatts
 
Posts: 75
Joined: Fri Dec 30, 2011 3:54 pm

Re: Model View Controller Architecture Issues

Postby mzechner » Fri Apr 13, 2012 11:04 pm

+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.
mzechner
Site Admin
 
Posts: 4709
Joined: Sat Jul 10, 2010 3:50 pm


Return to General Development

Who is online

Users browsing this forum: No registered users and 1 guest