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?