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?


3 Answers 3


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:



  • \$\begingroup\$ MVC can work well for FPSes see gamasutra.com/features/20050414/rouwe_01.shtml for at least one reference. \$\endgroup\$
    – stonemetal
    Nov 12, 2010 at 21:02
  • 3
    \$\begingroup\$ "...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. \$\endgroup\$
    – Engineer
    May 14, 2011 at 15:39

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).


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.

  • 2
    \$\begingroup\$ 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. \$\endgroup\$
    – MikeWyatt
    Nov 18, 2010 at 2:43

Not the answer you're looking for? Browse other questions tagged .