Sign in to follow this  

MVC Pattern. Is this correct?

This topic is 2951 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 re-working some things in my engine recently, and I'm trying to implement the Model-View-Controller pattern as part of this. I'm not really sure I'm doing it right though with regards to the view/model relationship. Currently I have various types of basic objects (the models), which currently are just acting as wrappers around PhysX objects, so I have box, sphere, capsule, mesh, etc, with public properties to access matrices for translation, rotation, scale needed for drawing. I then I have my views, which (taking box as an input model) are for example, wooden crate, filing cabinet, brick, etc. These contain references to the effect (HLSL), textures (diffuse, normal) and vertex/index buffers needed to draw them. It contains a reference to the model. Finally I have the controllers, which I won't mention any further, because I'm happy with the way they are setup. When setting up my objects I do as follows (psuedo-code):
Box b = new Box(...);
Box b2 = new Box(...);

CrateView crateView = new CrateView();
crateView.Add(b);
crateView.Add(b2);

Box b3 = new Box(...);

BrickView brickView = new BrickView();
brickView.Add(b3);

Renderer.Add(crateView);
Renderer.Add(brickView);
When Render() is called my renderer loops through each view registered and calls it's draw method. The View's draw method looks as follows:
void Draw(Matrix matViewProj)
{
foreach(Model m in models)
   if (m.InFrustum = true)
   {
      // Set effect world matrix as m.Scale * m.Rotation * m.Translation * matViewProj
      // Set Textures
      // Set Vertex/Index Buffers
      // Draw Primatives
   }
}

Is this the best way to decouple model and view? Is decoupling the two even needed? Should the models hold details of it's textures etc and the view be more generic, such as say MainCameraView, TopDownMapView. Since at the moment setting up lots of objects takes literally forever, and having different views for what are essentially the same object except for the texture seems stupid. The current views I have only really apply to the main camera, although the info I have in the models allows me to add to say a TopDownView which would hold it's own effect. I'm really in two minds about how all this should work.

Share this post


Link to post
Share on other sites
There is more to this, but i think you are on the right track in terms of following the pattern.

You are missing a Controller, which can be added to the Box in your example i believe.

I havent worked with MVC since my last job so i better stop there haha.

Share this post


Link to post
Share on other sites
The controller isn't missing, I've just omitted it from what is detailed above since I'm happy with the model-controller and view-controller relationships and separation.

Thanks for the comments.

Share this post


Link to post
Share on other sites
To me your application of the paradigm seems just a little bit "off".

The model in MVC does not refer to a 3D model, but to your model of the world.

So from an MVC point of view it seems unintuitive for the View layer to contain a crate and for a crate to be made of two model elements (boxes). Instead I would suggest a Crate would be in the model layer, and a CrateView in the View layer. The model layer is therefore a "model" of your "world" (players interact with a Crate), and the View a way of representing the model visually.

In terms of bringing box into it, the Crate would probably extend the Box (for example a crate is a box which can be opened), and the CrateView would extend the BoxView (the crate view renders like a box, unless the model is in the open state in which case it renders differently).

Quote:
I then I have my views... These contain references to the effect (HLSL), textures (diffuse, normal) and vertex/index buffers needed to draw them.


this part of your understanding is correct. If the textures doesn't affect how your objects act in the world then they are not part of the model, but texture selection may be based on the state of the model. Depending on your game model the vertex data may or may not be in the model layer (a complicated engine may use the vertices for collision detection, another model may user a tile based representation).

Share this post


Link to post
Share on other sites
I've done MVC a few different ways and it can be quite nasty when you use it for game/graphical things because you typically have models and views and all the terms mess things up.

I'll use a 3d modelling app type example as its a good place to use mvc.

Model: This is just your world, all the data etc. I sometimes put rendering code in here too although I'm not sure whats correct (its alot easier than reading all the data fwith a view and rendering). If you got a 3d modeling app then the model is your scene, all your objects, your camera, the textures etc etc

View: usually you only have one view but in 3d modelling apps you typically have a top/front/side/perspective view. Each one of those views shows the same Model but with different values, maybe using a different camera or drawing wireframe.

Controller: This is what links everything together, when you press a key the controller should decide what to do, if you right click and a menu comes up then the controller should decide what to do etc. I also have my controller resposible for calling redraw on my view(s).

You can have multiple models, multiple views and multiple controllers .

I can't say for sure whats right or wrong but your first snippet doens't look entirly right. I would say your boxes etc should be in some kind of Scene object (model), your controller should take the view and say "draw this model".

Where you put your rendering is up to you. I've tried model just having everyhting, view taking all it needs from the model and then rendering (nasty) and also having "Render()" methods on my model which just gets called by the view. I prefer the second option.

I would stick all texture and other drawing info into models. Your views just draw it from a different camera and with maybe different render settings (wire frame on/texturing off etc). Cameras themselves should perhaps belong to the model and just referenced by the view.

Share this post


Link to post
Share on other sites
I'm trying to figure out why you want to use the MVC pattern in an application like this. It's really meant for a sort of stateless GUI app like a web application maybe. What advantages does the pattern offer you in this case?

Share this post


Link to post
Share on other sites
Quote:
Original post by Pete Michaud
I'm trying to figure out why you want to use the MVC pattern in an application like this. It's really meant for a sort of stateless GUI app like a web application maybe. What advantages does the pattern offer you in this case?


That's what I was thinking, but without much experience in game design I wasn't sure if it was common to use an MVC pattern or not!

Share this post


Link to post
Share on other sites
I've always found MVC more useful as a paradigm for design than an actual implementation down to the level of naming your classes after it. MVC by itself is a higher-level pattern and does not always map well or directly to your classes. I'll chirp in here and recommend not to go overboard with MVC. Use it as a tool to help you think about how to structure your application conceptually, and to think about what your interfaces ought to be like, but don't get hung up on it.

On another note, the Model in MVC often can and does include business logic - classes or methods that manipulate the state of the model. Depending on who you ask, it is not just data, but note the difference between business logic and flow control.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
The advantages it offers are the same as in a web app. You often want to be able to change or use the visual representation and logical representation independently.


That seems clear to me for games where the model is quite separate from the view (e.g. you might model a game with a 2D tile-based map, but view it in 3D).

But does the same hold true when it comes to the modern style 3D games with strong physics? This is not a rhetorical question, I have no experience in this area, I would like to know!

Obviously you can apply the pattern, but intuitively it seems because the model and view are tightly coupled and that there might be a better (or at least alternative) paradigm...

Share this post


Link to post
Share on other sites
I don't see why it wouldn't apply. Physics doesn't need to know anything about how the object looks. It just needs to know about its physical properties. They may be created alongside the 3D model at authoring time but it's really a separate aspect. I should be able to switch to rendering in wireframe or sprite mode and still have the physics engine work precisely the way it did before.

Share this post


Link to post
Share on other sites
I too think MVC fits in nicely.

Renderer, physics, AI are views of the game objects model. The renderer displays them on screen, the physics engine takes care of collision detection and appropiate responses, AI reacts to model changes etc. the added benefit of the MVC pattern in this case is that all the other views will automatically be updated if the model is changed. For example, when the physics engine moves an object, renderer and AI are notified. This can be extended to user input and networking.

Typically, MVC is implemented using the observer pattern. Use a thread-safe observer implementation, and you can even put the views in different threads, which greatly reduces latency, which is especially important for networking. If you then have a music & sound FX thread that is also a view, you can react to changes in the game objects with sound effects, or even music changes.

Share this post


Link to post
Share on other sites
Quote:
Original post by dv
I too think MVC fits in nicely.

Renderer, physics, AI are views of the game objects model. The renderer displays them on screen, the physics engine takes care of collision detection and appropiate responses, AI reacts to model changes etc. the added benefit of the MVC pattern in this case is that all the other views will automatically be updated if the model is changed. For example, when the physics engine moves an object, renderer and AI are notified. This can be extended to user input and networking.

...


I somewhat disagree with your thinking there.

In MVC pattern you usually would have views only have read-only kind of access to models. This would be ideal. With physics being thought of as view for example, it has to apply changes to the models at some point in the process. It can't be exactly thought to be a perfect view becouse of this contradiction.

To apply changes to models in MVC you would use controllers to manipulate the data.

So there doesn't seem to be a perfect way to separate physics from models the way of MVC, unless we introduce physics controllers which get commands from some module listening to view ... but this seems to go a little bit on the side of overengineering?

Share this post


Link to post
Share on other sites
I would consider physics part of the model, and it would update periodically in the same way that it would without MVC. The model's state changes as a result and the rendering view (or networking view, or whatever) reflects that.

Share this post


Link to post
Share on other sites
Quote:
Original post by lightbringer
On another note, the Model in MVC often can and does include business logic - classes or methods that manipulate the state of the model. Depending on who you ask, it is not just data, but note the difference between business logic and flow control.


This is quite true, and in fact I don't see how you could implement MVC without "business logic" in the model. So including physics as part of the model, and passing it off to a physics sub-system with other data in the model in order to be modified fits nicely actually.

If you're going for separation and your entities are complex enough to justify the extra work involved, an MVC approach plus composition of different components for each model works pretty nice...

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
I don't see why it wouldn't apply. Physics doesn't need to know anything about how the object looks. It just needs to know about its physical properties. They may be created alongside the 3D model at authoring time but it's really a separate aspect. I should be able to switch to rendering in wireframe or sprite mode and still have the physics engine work precisely the way it did before.


I'm not saying it doesn't apply, I'm just wondering if there are other (common) alternatives or specialisations used in the 3D gaming world.

For example in (a strict interpretation of) MVC the model knows nothing of its views, but in many games things that are happening out of the players immediate area are not calculated.


Share this post


Link to post
Share on other sites
Quote:
Original post by taijianT
For example in (a strict interpretation of) MVC the model knows nothing of its views, but in many games things that are happening out of the players immediate area are not calculated.

That does not conflict with MVC, really. The world state is part of the model. That means the model knows where the player is and where the objects are (for instance, the transforms are stored in the scene graph), and can do the calculations as needed (aka when the controller tells the model to update itself as part of the game loop - notice that in a strict interpretation of MVC, your controller could nothing until it receives player input, and we wouldn't have an interactive game... so much for the utility of MVC ^_^;;;). Your concept of view in terms of 3D games might be a bit too broad - the view for games (or for any MVC application, really) is just what is being rendered, geometry chunks that are being sent to the renderer from the game world, where they are sorted and presented on screen.

So to answer your question, as Kylotan already said, yes, the model is quite separate from the view. The physics is part of the model (often the physics "engine" maintains its own internal model of the game world and runs a simulation on it - think collisions, springs, joints and such).

Share this post


Link to post
Share on other sites
Quote:
Original post by lightbringer
...So to answer your question, as Kylotan already said, yes, the model is quite separate from the view. The physics is part of the model...


My example wasn't so good, but my question is not really about MVC, I know it fits, and obviously physics is part of the model. I'm asking if there are other high level paradigms that are commonly used...
Quote:
Original post by taijianT
I'm not saying it doesn't apply, I'm just wondering if there are other (common) alternatives or specialisations used in the 3D gaming world.

Share this post


Link to post
Share on other sites
Quote:

Original post by Kylotan
Physics doesn't need to know anything about how the object looks. It just needs to know about its physical properties...

An alternative way to look at it would be to say that the way something looks is one of its physical properties. Or better ... the way something looks is a manifestation of its physical properties just as the way something moves is a manifestation of its physical properties. If we built up from this point of view we might have a paradigm which resolved around objects and interactions (or particles and forces)*.

That is not to say that this paradigm doesn't have a view, but view has been pushed down the conceptual hierarchy in the same way that the "physics module" is lower down the conceptual hierarchy than the Model or View in MVC.

*I'm not saying this is a plausible/tractable model (at least not now).

So one last time ... are there any other models/paradigms/high level design patterns (commonly) used for 3D games?

Share this post


Link to post
Share on other sites
Quote:
Original post by MediceI somewhat disagree with your thinking there.

In MVC pattern you usually would have views only have read-only kind of access to models. This would be ideal. With physics being thought of as view for example, it has to apply changes to the models at some point in the process. It can't be exactly thought to be a perfect view becouse of this contradiction.

To apply changes to models in MVC you would use controllers to manipulate the data.

So there doesn't seem to be a perfect way to separate physics from models the way of MVC, unless we introduce physics controllers which get commands from some module listening to view ... but this seems to go a little bit on the side of overengineering?


From my experience, the problem is that people tend to see the controller as one isolated entity, which is actually never the case. I have come to distinguish between a model centric controller half and a view centric one. The model centric controller reacts to model change requests from the in- and the outside, and notifies views. The view centric controller reacts to model changes, and to user input, or network input, physics changes etc. The view centric controller also takes care of updating the view.

This approach is necessary because part of the business logic (which is the contents of the controller) has semantics tied to the model, and other parts have semantics tied to the specific views. For instance, you need some sort of logic to translate XYZ position changes into network data packets, or 3D rendering updates.

Share this post


Link to post
Share on other sites
Wow, I didn't expect so many replies to this. Thanks for all the input from everyone.

I'd just like to add my take on the physics/model seperation that has been mentioned. The way I see it (and for my engine it's true) the physics IS the model. There are some side things such as for example life totals, etc. but the vast majority of the status of the game world is within the physics engine.

Share this post


Link to post
Share on other sites
Quote:
Original post by taijianT
So one last time ... are there any other models/paradigms/high level design patterns (commonly) used for 3D games?


Well, if you ask me, I think "just hack at it until we run out of time/budget and/or it looks correct, then push it out the door in time to meet publisher deadlines" seems to be the most common paradigm. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by taijianT
I'm not saying it doesn't apply, I'm just wondering if there are other (common) alternatives or specialisations used in the 3D gaming world.

I doubt more than 1 in 100 shipped games have any notion of MVC in the design. It's a new trend that's only really appeared on Gamedev.net this year. This has largely come off the back of the popularity of web games and specifically stuff driven by Ruby on Rails, Django, etc.

I don't think there are many or any other standard architectures for making games. I think generally you just make the classes that you need and refactor them to fit.

Quote:
For example in (a strict interpretation of) MVC the model knows nothing of its views, but in many games things that are happening out of the players immediate area are not calculated.

The model could include a description of the player's interest range. This may or may not extend to the device-dependent viewing frustrum, and it could come from the controller notifying the model about its rendering capabilities. (Note that in the original MVC, the View and the Controller were often 2 halves of the some component, eg. a Button).

Quote:
Original post by taijianT
An alternative way to look at it would be to say that the way something looks is one of its physical properties.

Of course. These are entirely arbitrary separations. Where you draw the line is up to you, but generally you pick the point that separates the set of base properties from changing representations of those properties. This requires a good understanding of what is likely to have multiple representations in your application, and what form those representations may take. I don't think there's anything resembling hard and fast rules in this area, especially not regarding games.

[Edited by - Kylotan on November 17, 2009 5:39:51 AM]

Share this post


Link to post
Share on other sites

This topic is 2951 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this