So, I decided to take a break from working, and write this short blog post on some of the back-end coding stuff that goes into Return All Robots. As you may (or likely don’t) know, Return All Robots is based off of a flash game we made at the 2009 Philadelphia Game Jam, called Shovelnose Screamer. The concept was essentially the same, but without all of the depth we’ve been adding in the XBox/Windows version. The programming team was really excited about getting a “second chance” with this game, because the Game Jam code had more hacks, kludges and band aids than any of us care to admit, and all programmers relish the opportunity to go back and do things the “right” way.
When we decided that we were going to do our game for XBox/Windows, we sat down and talked about how we wanted the game’s back end to run. There is a surprising amount of complexity, even in a “small” game, so it helps to have a game plan going into the game development process. So, as lead programmer, I decided that we were going to base our codebase off of the Model View Controller (MVC) design pattern. For the uninitiated, the MVC pattern splits every entity up into three main components: the model, the view, and the controller. Wonder where it got its name…
The Model is essentially all of the entity’s data about itself. In a game, it could be your health, position in the world, which weapons you have, etc etc. It is the authority on all of the object’s data.
The View is how the entity is represented. In web application programming, it’s generally the interface through which users see the entity’s data. For our game, the View (which I called the “Representation”) is actually pretty robust. It handles animations, animation state, and effects/overlays, as well as keeping track of where the entity is on the screen.
Controller is traditionally how the entity is modified. Which actions can be performed on it, etc, etc. In our set up, the controller is actually pretty synonymous with it’s concrete counterpart: the controller. For players, the controller handles the keyboard or game controller’s input, which action corresponds with moving up, pressing “A” to do something, etc etc. The controller objects don’t actually modify the object (as they do in traditional web-based MVC), but they do tell the object what it is being driven to do (which I think actually is more “correct” with the term “controller”). The model itself, when told to update, is actually what handles the input. However, the input forms can be abstracted, so the same model can be tied to either a game pad, keyboard in single player, or even multi-player mode using the same keyboard.
Using our MVC-ish framework has been really helpful. It’s allowed us to be very extend-able, swapping around models, views and controllers at our discretion. One time, one of the programmers created a level where all of the chairs would respond to the player’s calls, and were also deadly. I’m pretty sure I’ll forever afraid of rooms filled only with chairs. Creating new entities is also very easy, because we can just create a new controller type for the new enemy, and reuse existing views and models.
It’s not all rosebuds and kitten petals, though. If everything was perfect, then I wouldn’ t be writing about it here, but hoarding it, so that no one else could steal the awesome away (just kidding). One of the main problems we encountered early on is that entities in the MVC are inherently independent. One entity usually has very little effect on the other entities. In a game setting, however, this is less true. Things are bouncing into each other, you need to deal with draw order, and they’re actually pretty involved with each other. We had to create a way to have entities contact other entities, for the game engine to contact entities, and for entities to contact the engine itself (perhaps to notify the game that the player was hit by a bad guy).
All in all, we’re pretty happy with how the MVC-ish framework has worked out thus far. We’re pretty close to finishing up all of the programming tasks, and even though there are still definitely things we would change, I can tell you that our next game will probably be based on the same framework. Not to mention including lessons we’ve learned this time.
Category:
