Game Programming with Patterns: Model View Controller
For those of you new to Flash programming - or any kind of programming - you might not have thought about object oriented programming beyond just trying to get the stupid stuff to compile. When people think about OOP it drudges up ideas of classes, inheritance, methods, abstract members, and a bunch of other stuff that sounds great but how do we apply this to our great game idea? When you're learning object oriented programming the most important thing you can take away is how to use object patterns to quickly prototype your ideas.When people do medical research they don't start from scratch. They use libraries - buildings full - of previous research to build upon knowledge that's been growing for generations. When you're writing code there's no reason to start from scratch. People have built a huge array of useful patterns that we can put to work right away in our Flash games.
If you're interested in diving right in you'll love this huge list of design patterns. Today we're going to talk about using the Model-View-Controller pattern for game programming. This pattern has been popular in business software for a long time and has recently come into vogue because of the rapid rise of dynamic web apps. Check out Microsoft's Rob Conery (he loves MVC) who has been evangelizing the ASP.NET MVC platform for a long time now.
Bo-ring. I know. But how do we make it work in our games? Well the gist of MVC is this: you make a "model" of the things in your app, then figure out how to show them in the "view". Everything your user does is sent to a "controller". The controller then changes things in the model. Okay: we're still in outer space.
Imagine you have a hero. He's in the middle of the screen, and he's bored. Well what do we know about the hero? We know he has an x and y location on screen. What else do we know? He's got 100 hit points.
So lets turn this into a model. We'll mock it up in pseudocode. (This is great practice by the way.)
class Hero {
// properties
x:Number; // x location on screen
y:Number; // y location on screen
hitPoints:Number; // number of hit points left
}So we've got a funny little class. Now what do we do? Now we make a view. What does our view entail? Well it's everything we want to display. We don't know very much yet so we don't have a lot to display. In our game loop we usually take input, adjust variables, and then draw things. For our view we can just display the hero and a bar for his hit points.
class LonelyHeroView {
// a view always shows data directly from a "model"
var model;
function LonelyHeroView(hero:Hero) {
model = hero;
}
function display() {
// draw a hero at (x,y)
Screen.drawHero(hero.x, hero.y, hero);
// draw a hitpoints 10 pixels above hero
Screen.drawHitpoints(hero.x, hero.y - 10, hero.hitPoints);
}
}So what do we do with these two classes? Well we take our normal game loop and each time we create a "LonelyHeroView" and run display().
// set up our model before entering loop
var hero = new Hero();
hero.x = 10;
hero.y = 10;
hero.hitPoints = 100;
while(true) {
var view = new LonelyHeroView(hero);
view.display();
}Now our hero will be displayed every frame at 10, 10 and have a full bar of 100 hit points. Well we do want input don't we? Of course! All we have to do is take input and use the input to modify the model. We'll start by making a really simple controller class.
class GameController {
var model;
function GameController(hero) {
model = hero;
}
function left() {
model.x -= 5;
}
function right() {
model.x += 5;
}
}This is a really simple controller. We each turn in the game loop we have some new code.
// set up our model before entering loop
var hero = new Hero();
hero.x = 10;
hero.y = 10;
hero.hitPoints = 100;
while(true) {
<span style="color: #00ff00;"><span style="color: #ff6600;"> var controller = new GameController(hero);
if(leftKeyPressed() == true) controller.left();
if(rightKeyPressed() == true) controller.right();</span>
</span>
var view = new LonelyHeroView(hero);
view.display();
}Now we've got a simple model, view, and controller. One of the staples of good object oriented design is being able to separate code that's responsible for different things. The more complex your game gets the more your code is going to be stepping on its own toes.
It's always helpful to mock things up in your own language first, then pseudocode, then write the real stuff. There are even entire tools and languages dedicated to generating pseudocode! Imagine how easy it is to maintain your code now. What if you play the game and decide that the hero moves to slow? You go into the controller and make him move more left and right for each key press. Easy. Now what if you decide keyboard input is bad and you want to use the mouse for input instead? Just change keyPressedLeft() to leftButtonClicked() and voila your hero responds to a mouse.
I'll dig into more concrete examples of MVC in future posts! For now I'd really appreciate everyone's feedback on the first of my tutorials.


August 26th, 2009 - 22:52
Thanks Andy, that’s a pretty good explanation of MVC.
Good luck with your site – looks like you’re just kicking it off.
August 27th, 2009 - 07:00
Thanks a lot. I’ll be putting in some more examples and real code in the next couple weeks and then dig deeper into these patterns.
August 29th, 2009 - 12:07
Hey there Andy, I do a lot of MVC coding, but what I’m running into now is the use of MVC in gaming, which is what you just wrote about, but my questions are getting a bit deeper now, and I was wondering if you could possibly write a simple post on how one would handle a multi-player environment using MVC. I guess I’m getting a little lost because normally I have a model that handles all the elements in the game (so it can be displayed in any view), and then I have many views and many controllers, but now I’m seeing that I will probably need multiple models, but how can all my views keep up to date with all my models? Do they need to?
Thanks in advance Andy,
Gery
September 1st, 2009 - 06:50
Thanks for the question, Gery. I’ve actually thought a lot about this since your post and I’ll follow up with a more detailed post. I’m working on a couple concrete examples on MVC in a game and some other patterns, as well.
For your questions my basic line of thinking is a sort of controller that records input and can work closely with the model to re-create game states based on that timeline. Almost like an instant replay of the last 5 to 10 seconds of play in case things get out of sync.
October 22nd, 2009 - 18:13
Thanks for this, there are so few articles out there on game programming with mvc or composition (with actual code).
February 16th, 2010 - 16:15
Just what I was looking for to help get my head around how the MVC could be applied to games…
I was starting to hit my head against the problem of too much inheritance where every type of game object was starting to need it’s own branch on the inheritance tree, MVC looks like just the pruning shears I need! ;o)
February 16th, 2010 - 16:23
Great. Glad it helped. I’m going to be looking at expanding on patterns in games. Next I’m thinking of trying out dependency injection.