How can you organize the code for a game to fit the MVC pattern?

Asked 2009-02-17T01:59:04.210

I'm a freshman in college going for my computer science degree... I've programmed plenty the last several years but just lately I've been getting more into theoretical ideas about organizing code, design patterns, differences in languages, etc.

I have a Java class, so I've dropped my C++ research/development and moved into Java and JOGL (Java OpenGL). It's wonderful! But that's beside the point.

I want to make a small role-playing game, but this question really applies to any sort of game. How do you organize the game objects in a way that is structured, like the Model-View-Controller pattern? It looks to be an amazing pattern, very widely used and makes a lot of sense, but I'm having trouble figuring out how to implement it.

For instance, I need to keep track of a GL object for drawing to the screen. I have to have classes that implement MouseListener, MouseMotionListener, MouseWheelListener, and KeyListener (or one class, an all-in-one input manager). And I have to put my game data somewhere where all these different classes can access and modify it; if someone presses a button on the keyboard, the input managing class needs to somehow perform the action that the key is mapped to; when a frame needs to be drawn, the graphics class needs to find a way to loop through all the different 'things' and draw them all.

And my biggest issue, the GUI; where does it tie into it all? It's something like the input, but not quite, and it needs to both set and get pieces of data from the actual game simulation... And complicating it even MORE is if I decide to try and add networking, which (similar to the GUI) also needs to have access to a lot of the data for modifying and reading...

Oh, I'm just all confused. I don't know how to make all this work together in an object-oriented fashion... It's easy enough writing things that clearly fit the patterns, but when you have tons of things happening all tied to one game loop, modifying each

Edit Report

2 Answers

You're getting along there. basically, ask yourself the question "which code would change if I had to change some part of the program?"

If it would change the way it looks without changing basic data, then it's in the view. If it is data that could be viewed in many ways, it's the model. And if it's how you play, then it's the control.

So if it's whether you draw an "axe" with two blades or one, it's view. If it's how many hit points damage you inflict with an axe, it's model. And if it's whether you swing the axe by typing "s" or by right clicking, it's control.

answered 2009-02-17T02:26:17.093

I feel with you I remember when I first discovered MVC I tried to cram everything into it. I did indeed make a game that utilized MVC pattern. What I have found later though was that what I did was overkill. I tried to fit pretty much every single class I made into one category in MVC.

What I suggest is to read "Design Patterns" by the gang of four. There are a lot of useful patterns besides MVC. Sometimes it doesn't make any sense to use MVC at all. Especially for games I am not sure if MVC is such a good idea. The reason being that you don't want to display a game object in many different ways (views), but you want to reuse a drawing code for many different types of game objects.

For my own 2D game engine I used the strategy pattern quite actively. The game objects, like the player and the monsters I called a Sprite. I let the drawing of the sprite be handled by a strategy pattern. That is when I called sprite.draw() I would do something like this:

class Sprite {
  void draw() {
    this.view.draw(this.currentPosition, this.currentOrientation);
  }

  Point  currentPosition;    // Current position of this sprite
  double currentOrientation; // Facing angle of sprite
};

The benefit of this approach is that you can share a view object between several sprites. Because typically there will be a lot of e.g. monsters which will look the same but which will be a different positions and possibly behave different.

So behavior I would also use a strategy pattern which would be a object which contains code describing behavior. That way I can apply the same behavior to several monsters at different location. So each frame I would call an update() function to update position orientation and what monster does.

class Sprite {
  void setUpdateAction(Action action) {
    this.updateAction = action;
  }

  void update(double st


                        
                        
                            answered 2009-02-17T06:18:42.057



        
        
            Your Answer