Is MVC(Model, View, Controller) concept applicable on C++ game programming?

In the MVC design, one of the concepts is the model notifying the view that it has changed. For static displays of information or even graphics, that works well. However, a lot of games (most?) update the view on a regular basis (frames-per-second), so there is no need for the model to notify the view when it changes. The model is displayed each frame in its current configuration. If the model has changed since the previous frame, its shown as updated.

The "controller" module in games is often a separate set of routines doing I/O and, in fact, similar to MVC, updates model and display parameters. It just isn't called a "controller."

Microsoft's Document-View architecture with its message structure to notify the view when the document is changed, is somewhat similar to MVC, without a specific controller function. But, as noted above, if a game updates the view regularly, why tell the view that an update is required?

It all depends on the game type and so on. if you have a very static game the MVC web model might be just as good as any other form av design.


On the other hand if you put new interpretations into what the MVC stands for id say its very much applyable.


Currently i am trying to apply this thinking to a small tower defence game i am messing about with.

Model = The object of the worlds collected data. It's just pure data. And could have many sub models depending on your needs.

View = Interprets the Model data and renders it into view. Depending on your preference you could make it render to a file for say pdf or a 2d render or web render if you want. it's just the way to interpret the data of the Model.

Controller = The way to modify the Model/ data. It could be stuff like network controller or AI controller or human controller and so on. This is the way to modify and or change the data.


Not saying this is correct or anything just saying that this is something i have been playing around with for fun. And haven't used it enough to determine if its effective or useful yet.

Shell Shock: Nam '67 is an FPS that used MVC and the devs were nice enough to do a write up on it over on gamasutra.

If MVC is not the popular model, what is the design model people usually use? I have seen people putting draw functions in every class. Is that how it usually works?

I have a View class which has functions like draw_background, draw_pieces, update_screen. So at the end of the game loop, I just call the functions using the View object.

I still don't know if this is a good take on the programming design, but the game works and it's easier to locate codes that's relating to drawing on the screen.

Thanks.

eAGLE

A general approach to a game loop:

- Get user input (mouse pos, keystrokes, etc.)
- Update camera direction/position, model positions, etc.
- Draw - you can call each entity to draw itself based on updated parameters
- Repeat

Quote:

Original post by Buckeye A general approach to a game loop: - Get user input (mouse pos, keystrokes, etc.) - Update camera direction/position, model positions, etc. - Draw - you can call each entity to draw itself based on updated parameters - Repeat

Quick question.
If one day I decide to switch to another graphic library, for example, from SDL to OpenGL, I will need to rewrite all the drawing functions in every class if that's the case. But if I put all drawing functions in one class, wouldn't it be easier to switch library just in case? I am just wondering, I could be wrong.

Thanks,

eAGLE

To this end, I find it more practical to use a "Renderer" which read informations from objects and render them rather than asking the objects to render themselves. Objects classes shouldn't know nothing about the graphical API.

Quote:

Original post by Dunge To this end, I find it more practical to use a "Renderer" which read informations from objects and render them rather than asking the objects to render themselves. Objects classes shouldn't know nothing about the graphical API.

That's what I am thinking as well. But do we actually create a Renderer class? or defining a bunch of global functions would be a better design?

Thanks,

eAGLE

[Edited by - eagleyeh on May 27, 2010 10:11:41 AM]

Quote:

Original post by eagleyeh I can see how MVC works in game developing, but is there a reason why this design is not popularly used among game programming? or I just haven't seen enough.

2 simple reasons:

1) MVC is a new fad. That's not to say it's bad (it's not), or new (it's not), but it's only recently that it's exploded onto the scene as The Way to do things. How did this happen? Well...

2) ...MVC got popularised by the web development community, mostly when they realised that munging logic, structure, and presentation all in one file (ala traditional ASP/PHP pages) was an amazingly poor idea. Luckily someone rediscovered MVC from bygone times and made/refactored web development to use this improved system. MVC is a system for developing GUI apps, which is why it's so universal in web development - almost everything they do is a GUI app, essentially. Other areas of computing are not so tightly bound to the need for user interfaces, and especially not user interfaces that exist on different machines to the business logic.

MVC can certainly be used for game development, and sometimes already is, just not formally. People have long tried to separate an entity from its visual representation (splitting off the View from the Model) and sometimes people like to make an entity's interface abstract so that it can be controlled by a player or by the AI (splitting off the Controller from the Model).

MVC is encouraged where I work.

The important thing is to not use MVC religiously, some things may only need a Model and a View, or just a Model. Use common sense to decide when it is appropriate to separate things. We usually start with the Model and separate things out as is appropriate.

As a trivial example, you might want to have a scoring model implemented separately to the game model. The game controller passes events to the scoring model and the scoring model calculates score, multipliers etc. The games "canvas" then queries the scoring model for the score and renders it on screen. This allows you to swap in and out different scoring models when tweaking without modifying the game. In this case the view and controller for the scoring model would be the game "canvas" and game controller, you don't need a score controller and a score view.

The concept you used in your tetris clone is pretty much the basic Update-Draw game loop that is most usually used (as far as I know) just with different names. Update = Control, Draw = View, dunno what Model would be.

Quote:

Original post by eagleyeh Quote: Original post by Dunge To this end, I find it more practical to use a "Renderer" which read informations from objects and render them rather than asking the objects to render themselves. Objects classes shouldn't know nothing about the graphical API. That's what I am thinking as well. But do we actually create a Renderer class? or defining a bunch of global functions would be a better design?

Create a Renderer class, though I'd call it an ImageManager instead. It should handle loading assets in addition to drawing them (since both tend to be dependent on the graphics library you're using. Because of this, it can cache loaded images and save disk access calls. This requires internal state which isn't practical with just a bunch of global static functions.

As it happens, I recently decided to switch my program from SDL to OpenGL, and all I had to change was the code that sets up the drawing window and the code in my ImageManager class. Everything else didn't care one bit. Well. I tell a lie -- I'm still working on the font-drawing code, which is neatly sequestered in my FontManager class. Everything else worked fine, though.

Quote:

Original post by eagleyehQuick question. If one day I decide to switch to another graphic library, for example, from SDL to OpenGL, I will need to rewrite all the drawing functions in every class if that's the case. But if I put all drawing functions in one class, wouldn't it be easier to switch library just in case? I am just wondering, I could be wrong. Thanks, eAGLE

I have been thinking about this as well. Right now, I am doing my work purely in 2D and SDL. However, I set up my design such that all my SDL related interfaces are in a fixed set of classes. So when I do decide to change libraries, I have contained the amount of change to consider.

Then again, at this point my experimentation, it is really kind of moot. I suspect that I will rewrite many of these before I even get to some type of 3D library. So I am not too worried about future extensibility yet.