Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I was contemplating the design of a game (translating a boardgame to the computer, specifically, which I suppose is relevant in this case) and it occurred to me that it might make sense to build the 'game' separate from the 'display.'

It would allow me to prototype something quickly with a simple text interface, and then go pretty it up later. It would also let me port the game to other media more easily.

Is this sort of compartmentalization common in games? Should I try to break things down further? Are there complications I might be missing?

share|improve this question

closed as too broad by Josh Petrie Apr 21 at 19:58

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers 3

up vote 6 down vote accepted

A board game is a good example of a game that could be made using MVC, as the game logic (model) does exist quite independently of the visuals (view). However if you consider an action game like Gears of War, the geometry of the 3D models is intrinsic to the game logic, so separating out the view as if it were interchangable becomes pointless. Unity3D is a great example of a more game-specific way of organising code. You have a base entity class which you add functionality to with components, where one component might handle drawing the entity, one handle game logic etc. Check out these famous blog posts on the subject:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://gameprogrammingpatterns.com/component.html

share|improve this answer
    
MVC can work well for FPSes see gamasutra.com/features/20050414/rouwe_01.shtml for at least one reference. –  stonemetal Nov 12 '10 at 21:02
2  
"...geometry of the 3D models is intrinsic to the game logic..." Thus the geometry becomes primarily model data so as to be manipulated by the controller (in this case, it affects physics, so it exists with all other physics parameters) for game logic purposes. If it also happens to be used for the view, as in this case, then that is considered as secondary, as the true simulation is the controller affecting the model; the view is irrelevant. (Some quibble over whether configuration data should exist in the model; up to you, but the principle remains the same). This is a purist approach. –  Nick Wiggill May 14 '11 at 15:39

That kind of compartmentalization is the split between an Engine and gamecode, and is quite common. There is plenty of room for abstraction along the way.

Your Engine and your games specific graphic data could be though of as the View, your gamecode the Model, and the controller would be whatever glue you use to tell your engine which texture to apply to which entity in your gamecode.

share|improve this answer
1  
This is not at all true. MVC defines the separation of state (the model) from the user interface (the view and controller). An "engine" is a generic framework on which games can be built, and could contain the base elements for the model, view, and controller. –  MikeWyatt Nov 18 '10 at 2:43

My take on it:

  • The model is where most data lies and all logic takes place.
    It reads a queue of input events, and modifies the game state accordingly.
    It then processes stuff like physics and other core components that also update the game state.
    Loop. That's all.
    The goal is to make the model independant: it doesn't have any dependency on view or controller stuff: you should be able to make a program that only runs a model.
  • The view simply reads the model's game state, updates its own components dedicated to the representation of the data, and display things on the screen.
    It never writes anything on the model, it's a read-only process, except maybe the registration of some event handler (like "Hey Mister Model, when you detect a collision between those two objects, please call my event handler that plays a sound!").
  • The controller catches input events and passes them to the model's input queue. It reads the view (did this button click happen on a UI button?).

That way you can plug a fake controller that reads a file that contains pre-recorded input events.
Also make a simple view that just logs things on a file.
Very usefull for testing and debugging.

Remember to make the model update at a constant rate (fixed time step), and the view and controller as fast as possible (but not too much variable).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.