Jump to content
  • Advertisement
Sign in to follow this  
Maxamor

MVC, Object construction, help!

This topic is 3715 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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); // Reference
ZombieView 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)?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!