   Is MVC(Model, View, Controller) concept applicable on C++ game programming?
  Hi all,I used to build websites following MVC design. However, I find this design is rarely used in a lot of tutorials I've read about game programming. 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.By the way, if people actually use MVC design in their code, how they actually do it? What I did in my Tetris clone was to create two classes called Control and View. Control handled all the game logic and View handled everything showed on the screen. Thanks in advance for all your opinion.eAGLE   
  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 BuckeyeA 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- RepeatQuick 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 DungeTo 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 eagleyehI 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).   