MVC Paradigm for games?

Apprentice
Posts: 14
Joined: 2008.10
Post: #1
I was wondering if the model-view-controller paradigm works for games. In my tic-tac-toe game, I ended up using my custom view as both view & controller, primarily because I wasn't sure how I would access objects in one class from another class without instantiating one or the other.

The problem doing it the way I did is that the code is kind of messy, because you are doing everything from within your view. Any thoughts on this subject?
Quote this message in a reply
Moderator
Posts: 592
Joined: 2002.12
Post: #2
Yes it does work.

The model contains your game data.
The view displays your game data. Mouse input received in the view is passed to the controller.
The controller calls the relevant methods in your model part for making the changes to the data based on the input received.

In your case, the model would contain the game board.
The view displays the board and passes the mouse input to the controller.
The controller checks to see what part of the game board you have clicked on and then calls the relevant model methods to update the game board.

I hope that helps. MVC is not the easiest of things to explain to someone.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #3
MVC actually works at different levels in games. For once, you have the GUI of the computer, the user input machinery, and your game simulation. This is the macroscopic MVC pattern of a game. You can also apply it microscopically, to the game entities themselves, by separating model (eg your physics model), view (drawing and sound functions), and controller (input, AI). It does not even have to be separate classes, as long as the functionality is discernable by the MVC pattern.

It all depends how you chose to look at things, and always remember that using a pattern does not necessarily mean your code could not be interpreted applying a different pattern.
Quote this message in a reply
Member
Posts: 156
Joined: 2002.10
Post: #4
I can see how you could easily be confused between View and Controller in Cocoa, where your (custom) view recieves mouse events.

In my setup (SDLGameBase 0.2 - plug, plug Grin ) The main game loop runs, polls for events, and if there are, delegates to the controller class. It then sends the time since last loop to the model, so it can update itself, and finally calls the View to redraw the screen. In my case, the Controller knows about both the Model and the View (it needs to be able to control both of them) and the View only knows about the Model (so that it can draw it on the screen.

There are two ways to go with drawing objects:

1) Each object has a Draw() function which draws that object. It may require a pointer to the screen surface or something to be passed to it in order to draw itself.

2) The View itself stores info on how to draw the various objects, and when drawing, requests the co-ordinates of the objects and draws them.

I do mainly the 2nd method, but my objects also hold a variable called imageID which tells the View what sprite to draw for that object. So as well as the co-ords, the view also asks each object what it's sprite ID is.

Hope that helps.

- Iain
Quote this message in a reply
Post Reply