I've been working on separating my game objects from their views. I am confused as to what role the controller plays or how it exists as an object. Say I have a model, "ZombieData" and a view "ZombieView". My "game world" is the controller which glues these two things together -- right? If that is true, where does the logic specific to a Zombie live? Within the ZombieData object or somewhere else? Does this mean the model is more than just the state or "data" part of the Zombie? If that is true, how do I go about constructing both of these objects in parallel? Is there a generic way of going about it? I feel like I'm really close to getting this right, can anyone point me in the right direction?

The 'proper', or at least original definition of a controller in the model-view-controller paradigm is that the controller takes the user's input and modifies the model. This is then reflected in the view. A graphical component would therefore be a controller/view pair, and this pair could vary independently of the model that represented the actual data.

Confusion sets in because MVC is/was not a generic design pattern, but actually a GUI design pattern, and the View is specifically how to present the item to the user and the Controller is specifically a user's input method. Often people try and apply MVC to applications that aren't simply GUI apps, and therefore the system doesn't apply quite so cleanly: who is the user entering input on behalf of that zombie?

In the spirit of the original MVC, I'd say that the controller for a zombie is the artificial intelligence. It's the external process that sends input to the zombie model, which is later reflected by the zombie's view.

When the game world creates a zombie, it should therefore need to create a ZombieController object of some sort, and associate it with your ZombieData. Periodically (ie. each update tick, or whatever), you tell the ZombieController to update. That will presumably collect whatever information it needs from the world, and make modifications to ZombieData as it sees fit.

Is there much benefit to this method? On one hand, it's possibly a bit contrived to separate the ZombieController from the ZombieData, as obviously the controller must depend extensively on the ZombieData to do anything useful. On the other hand, you could experiment with swapping out different ZombieControllers, perhaps with different AI models, and have them operate on the same generic ZombieData quite easily. You could even swap in a controller that takes mouse/keyboard input and lets a player move the zombie.

I don't want to hijack the thread, but I've approached this problem in a similar way to that described by Kylotan. In my case it was a very simple PacMan simulation. I know - sledgehammer, fly, etc. Anywho, the purpose was to apply MVC to a simple scenario.

Essentially I have an MVC triad for each character. Just as Kylotan says, the controller takes any input, feed it to the model, and tells the view when to draw.

The problem I ran into was when I started integrating all of these MVC triads. PacMan, each ghost, power-ups, and fruit all have to have a place to be drawn and they all exist in a larger world - the maze. I ended up have a Maze (or World) MVC triad that essentially encapsulated all the rest. It has its own data - the maze walls, locations of the food pellets - and supplies the view to which all the characters draw. In turn, it then is the master drawing object that is copied to the screen.

Any thoughts on this hierarchical approach?

-Kirk

I think the main benefit of MVC is that it sort of breaks up the idea of having one monolithic composition hierarchy of 'objects' that supposedly manage everything about themselves, and instead an object becomes a reference to 3 aspects, its model, its view, and its controller. Each of those can be aggregated in whatever manner you need.

For example you might have the views in a scene graph so you only render what you need, you might have the controllers in a list so you update each one in turn once per frame, and you might have the models implicit in an SQL database which you modify attributes on as necessary.

The Pacman example sounds to me like a model-level hierarchy - objects in the world exist as part of other objects or within other objects. If you want to implement that as C++ composition, that's fine, just as long as you have a reasonable way to manage the lifetime of the associated views and controllers, and that's really getting down into memory-management minutiae.

I'd argue that the important thing about MVC is not how things are stored, but how things are NOT stored - view information is in a separate object to the controller information, which is a separate object again to the model information. This lets you vary them independently and keep the behaviour well partitioned and hopefully re-usable. How you choose to go about using the individual components is up to you.

Thanks for the responses. This is all great stuff. If I were to set it up like this and have three components per game object, at construction time I imagine it would look something like this pseudocode:

ZombieData data;ZombieController controller(data);  // ReferenceZombieView view(data);  // Const Reference

Both the view and the controller hold direct references to the data? I don't need to rout changes in the model through the controller to the view, right?

Where is the data created so that it doesn't get destroyed by going out of scope? Should I store it in a shared_ptr and pass that to the controller? Or should I just store it in another bucket in my game world (like the views and the controllers)?

Another question/scenario to add to Maxamor's list. I've done MVC in the past with non-game applications and it made much more sense. The reason being is that there was always one model, multiple views. For example, one set of tabular data and many different charts of that data. Even in my simple PacMan I ended up with multiple views and multiple models. It was the integration of the multiple models that led to the World object that was composed of the sub-MVC triads.

Is this multiple model scenario unnecessary or have I just over-complicated my system?

http://www.codinghorror.com/blog/archives/001112.html

^^Behold MVC in all it's glory.^^

Model - a model isn't just the data it is the full representation of the object being modeled.

view - A view is a visual representation of its model.

Controller - Links the user to the model by controlling the view and sending input to the model.

as a diagram user <-view
^
|
user->controller<->model
Edit:
It doesn't seem to like my spacing that arrow should be pointing at the view. from the controller.

Quote:Original post by stonemetal
...
Model - a model isn't just the data it is the full representation of the object being modeled.
...

So in this case the model (my "ZombieData" object) has both the state information and the AI logic -- right? The only thing the controller (my game world) offers is interaction between the user and this model. Am I following?

EDIT: Also, does it make sense to have an instance of a view per instance of a data object? If the view can determine what the data should look like at any point in time wouldn't only one view instance be required?

In my opinion, I wouldn't mix the AI logic into the model object. Your ZombieData object would have only information specific to describe the zombie - location, state, orientation, health, weapons, etc. The AI logic would go either in the controller, or you might have a ZombieBrain object that accesses the ZombieData and other data as necessary, performs some calculations, and then modifies the ZombieData as a result of the AI decisions. I would call it from the ZombieController in a normal update loop.

-Kirk

I'm leaning toward doing that myself. I will implement a test of having a "triad" per game object and see how it goes. Thanks for the ideas.