Does Box2D breaks MVC concept?

Question

Box2D suggestes a physics engine for games which combines and model and view. Now I want to use MVC design pattern or a framework based on MVC design pattern such as Robotlegs of PureMVC in order to create a game. If I choose Box2D, is it true that Box2D breaks MVC concept? And if it is true, should I worry?

Answer 1

I don't feel the Box2D breaks the MVC concept at all (as long as we are talking about Model-View-Controller here...I often get lost in the acronym ocean ;).

The physics is part of the model. Not the entire model.

Consider the simulation of a missile in flight across a 2-D landscape (e.g. this). The "missile" has a model of how it moves. Part of that is the mass, moment of inertia, velocity, etc. This is the physical part of the simulation.

It also has some kind of "AI Code" to decide how much force to apply, how to turn the missile, etc. These or often called "steering" forces. This is the next level up of the simulation, the "getting things moving" part of it.

There is also a larger part of the model, the part that decides what to do when the missile hits something (which it gets from the physics). Or when to fire the missile in the first place. Or the route the missile should take.

You can go even higher, probably, but the point to take away from this is that at no point have I mentioned how the missile is displayed or presented to the user. That would be the view.

So, my take on all this:

The Model (in layers):

1. PHYSICS
2. MOVEMENT
3. LOGIC AND REASONING
4. OVERALL SIMULATION or STRATEGY

At no point is the View mentioned in any of these...they operate and exist regardless of whether they are displayed in 2-D, 3-D, or by balloons tied to chipmunks. The layers may interact with each other...the physics detect a collision that ends up causing change in state in the LOGIC AND REASONING layer, etc.

For completeness, the controller brings the user into this. The user "uses" the controller to manipulate the model. I've always felt this was a little hard to think about; I like concrete examples.

On the "hard core definition" level, the user uses the controller to give input to the model. So I touch the screen and the missile knows where it should fly towards. The model gets a command to "go here" and the AI of the missile takes this command and "runs with it".

On the other hand, the controller may also be used by the user to manipulate the view (which is not part of the "hard core mvc" definition. Consider a tablet applications where a pinch changes the viewport but a tap signals the missile to strike "this target". The first changes the view while the second changes the model. NOTE: This situation may be a manifestation of more modern forms of patterns derived from MVC, and not pure MVC.

Regardless, the physics is part of the model, not the whole model.

Was this helpful?

Answer 2

No, it's not true that Box2D breaks MVC. Box2D doesn't combine the model and view, in fact, quite the opposite. Box2D is completely agnostic about what you choose to render your view, so it's highly compatible with an MVC architecture.

Games are conceptually tricky when considering MVC because the model has many parallels with the view (unlike a business app). However, you still get lots of benefits from separating concerns in your architecture.

As Fuzzy says, Box2D is part of the game model.

MVC in a game looks like this:

Box2D will get wrapped in game model classes. Your rendering library (you haven't said what platform you're writing for) will get wrappped in your View classes. Any UI stuff goes in your Controllers.

If you want read more about how to use MVC for HTML5 Games using Box2DWeb (for physics) with EaselJS (view) in CoffeeScript, I've written more about it here.