MVC-like compartmentalization in games? [closed]

Question

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?

Answer 1

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

Answer 2

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

Answer 3

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.