Model-View-Controller (MVC) in Games

General Discussions
#21

I agree up to a point. But it is a different thing if you make a component or framework for yourself, or if you propose a design to be used by others.

They need something flexible, configrable, parametrizable, robust and still easy to understand. Developing re-usable components (or even libraries) is a whole level more demanding than writing code for your own project.

if you propose a design as tutorial, I think that is has to have some of the properties. if the tutorial is not meant to propose a implementation, but only an idea, you miaght want to strip down the implementation to the code parts needed to explain the idea, and let the user work on an implementation that they like.

#22

I tried working with MVC when learning to write games a few times (I found it to be very useful in business apps), but in my experience it becomes a mess if you try to make a game that is not completely trivial. It’s a nice idea, and it’s well worth it to try and keep things decoupled, as long as it helps you in Getting Things Done. Once it gets in the way, just throw it overboard. Somehow games are not so well suited for an MVC approach, with their extreme emphasis on linear real-time operation, fancy graphics, and a very close integration between view and model (unlike business apps in which model and view usually are completely different worlds). MVC is just not so useful in games IMHO.

That said, this explanation of MVC just does not make things any more clear. Any beginner just would get confused by reading this, and people who can make sense out of it already know and understand MVC, and hence do not need this. Most importantly, it does not give a reason why anyone would do this: “Your Model classes are completely portable, decoupled from a graphics library” is what MVC is; it is not the reason for using MVC.

To conclude, some advice which I think would make this a more useful tutorial:

  • Give a reason why anyone would bother with MVC
  • Provide a lot more explanation: a tutorial on MVC for people who already understand MVC?
  • Discuss when NOT to use MVC, or when to stop strictly following this pattern
#23

No, what I was asking is what’s the argument for using this as the high level abstraction model? What use-cases does it work well vs. poorly? I look at it and think: Does this help with high behavioral complexity? No. Does this help with high loads of many entities (improve temporal coherency)? Not really. So what’s the use-case? When is it the optimal solution (using an engineering time to meet a specific design as the metric kids)? I can’t think of a situation where going this route is a win vs. other models.

#24

Using MVC blindly as a tome of faith when developing your games is going to lead to overcomplex spaghetti code, class proliferation, and eventually, not much game. There are places where it makes sense - networked games - but for solo experiences, keep it simple!

We at Puppy Towers entirely separate the code behind rendering and the code actually powering the game. Rather like Swing we sort of collapse our model and controller into one.

Cas :slight_smile:

#25

(IMO: you can replace “MVC” with “design patterns” here).

#26

Design patterns = something invented for mediocre J2EE programmers so they all get along nicely doing what they’re told and the project manager can cover their ass.
* princec dons flame resistant pants.

Separating logic and rendering is great though, any game of moderate complexity benefits hugely from it.

Cas :slight_smile:

#27

I would actually believe that, if the book aptly named “design patterns” wasn’t actually written for C++ and Smalltalk programmers :wink:

There have been hefty discussions about design patterns before, lets not repeat them. I’m sorry for having dropped the term again.

#28

Design patterns are just names for things that are already best practices. Just like religion and politics, when the symbol becomes more important than the principle, that’s when you run into problems.

#29

Design patterns are awesome because we all know that computer science is: the square problem, the circle problem and the triangle problem.

#30

The MVC pattern is perfectly valid for games. This blog post was basically written about the observer pattern, but is all the same an MVC illustration.

#31

Where’s the beef? Validity isn’t the problem. The core issue is meeting one’s design spec at minimal engineering costs. Sure you can implement the walk of a red-black tree as the visitor pattern but it’s pure wankery.

#32

“Controller : the behavior of a model, modifies the state of an object”

In my opion, this is one of themost common falicies of MVC. The role of the controller is actaly quiet specific, although very badly name. It’S roles is to intepret user gestures from the View and interpret them into something the model can undertsand.

The model should contains not only the state but the behaviour of the model. Otherwise you get an anemic domain model hhttp://martinfowler.com/bliki/AnemicDomainModel.html.

Which ican be ok, but misses out the OO goodness. Also pushing more functonility into your model makes it easer to write unit tests - the model is the most easily tested.

#33

I don’t know how to properly implement the true/real MVC in game but I tried. It’s close enough and works fine.

#34

to follow up, the role of the Controller is to interpret events from the ui and interpret them into the language model.

It isn’t a place to put ‘control logic’ which is pretty meaningless.

Anyway, I’m glad your solution works.