Jump to content
  • Advertisement
Sign in to follow this  
adt7

MVC Pattern. Is this correct?

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

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
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!