Quote:Original post by Maxamor
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?
Given the original definition of MVC that I cited, that is correct. Unfortunately, as you will have seen elsewhere in this thread, not everybody goes by the same definition, which adds a lot of confusion.
Quote: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)?
Wherever you like. That consideration is outside the scope of the problem MVC is trying to solve. But the important thing is that the Model 'is' the item in question. The controller and view depend on it. It's not part of the controller or owned by it. The model is conceptually part of your game world.
Quote:Original post by kirkd
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.
Yep, exactly. It fits well with the typical scenario of a business storing important information in an SQL database and presenting it via a web page or a simple client app.
Quote: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?
You're perhaps confusing the MVC paradigm for a design pattern. On the micro-level - ie. where all the examples are, unfortunately - you have 1 class for the Model, 1 for the View, one for the Controller. But that is really just to demonstrate the concept. MVC isn't really supposed to dictate the class structure you have, more the logical structure. Your various items that make up the world are 'The Model', the various classes that allow you to render them on a screen are 'The View', and so on. In any non-trivial system, each of the 3 parts will consist of many classes, and how you choose to arrange those is a sub-problem in itself.
In a very homogeneous system, you may get away with 1 of each class for each item, such as in the original idea of using MVC for GUI widgets. But the problem you are trying to solve is so different to that original problem that trying to be rigid about it instead of following the 'essence' is going to do more harm than good.
Quote:Original post by Maxamor
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.
Where to split the logic depends on your design really. Is a certain behaviour or function intrinsic to Zombies? If so, it's part of the model. Or is it only intrinsic to how it is being controlled or manipulated? If so, it's part of the controller.
Quote: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?
Depends on the system. As I mentioned above to KirkD, MVC is not about prescribing classes, it's about prescribing divisions. The important thing is that the view system asks the model system what needs to be presented, and then does it. The number of classes you use to achieve that is up to you.
Quote:Original post by Shakedown
Quote:
So in this case the model (my "ZombieData" object) has both the state information and the AI logic -- right?
Another way to do it:
No. The AI logic is simply another type of a View. Your models should contain only the necessary data (state information) for them to function. AI logic is not necessary data.
Your Views are what control the Models.
Without criticising the design itself, that's not how MVC works. Views are for presenting models, and that's it. The Controller controls the Model, hence the name.