The model-view-controller (MVC) design pattern is a wonderful — and almost entirely necessary — thing in game programming. Today’s post won’t hold (m)any surprises for readers who are already familiar with the MVC pattern, but it could be somewhat informative for anybody just getting started with game development — or the development of any sort of application, for that matter. I’ll be discussing exactly what MVC means, what it’s used for, and why the development of a game can benefit so much from it.
Model-view-controller is, as I mentioned at the very beginning of this post, a design pattern, a template for solving a particular problem or type of problem. We’ll discuss the particular problems that MVC solves momentarily, but I’d like to describe what it is, first. As the name suggests, there are three components to MVC: the model, the view, and the controller.
The model contains all of the information that drives an application; in the case of an MMO, this would be something along the lines of character names, stats, the layout of the various maps in the world, where a particular person is, the dialogue for quests, etcetera. It’s a representation of everything that makes your game yours — all of the information that makes up the game’s core.
The view, on the other hand, is not tied to the actual content of the application at all. It simply describes the manner in which content is displayed to the end-user. To that end, the view component of an MMO or any other video game is a collection of functions and classes describing how the information contained in the model should be represented on the screen. A “graphics engine”, as you’ve doubtlessly heard it called, doesn’t need to know anything about how the game it’s rendering actually works; it only needs knowledge of what a player should see, and how the changes that occur in the model alter what is seen, in order to determine what needs to be shown to the user.
The controller, finally, is the portion of this trifecta which allows for the model to become something dynamic and interactive, as opposed to something static like a movie or story. It defines the various manners in which users can provide input to your application, and how those inputs are converted into something the model can understand. The controller is what defines the user’s controls for the application, meaning, in terms of game development, that it defines the player’s controls.
What is the point of separating things out in this manner, though? Well, for starters, partitioning the rules that govern how your game world works and the content that those rules have an impact on from the way that your world appears to the player means that you can completely change the appearance of your game without changing any of its fundamental mechanics. A game that takes place entirely in two-dimensions can be represented in impeccable 3d graphics, a la Little Big Planet, Super Smash Brothers, or any of a vast number of other games. The same goes for the controller; by abstracting out the manner in which players interact with the game, you make it easy to change that manner of interaction without having to alter any other portion of the game. A clean interface between the model and controller means that controlling the game in a new manner (a touch-screen versus a mouse and keyboard, for example) only requires you to write code to support the new method of input, instead of having to rewrite any of the code for the game itself.
The opposite of the above concepts are also true. While Model-View-Controller makes it a simple matter to switch out the rendering and control processes for your game, it also means that you can reuse the classes and functions you write for the view and controller for several games. As mentioned before, the view component is often referred to as a “graphics engine”, something that can easily be be interfaced with any game engine that provides just a few specific types of information, meaning that the initial time invested in creating a graphics engine often saves you work in creating future games; this defines the business model for certain companies, who make their money by creating richly-featured graphics engines and licensing them out to game developers who are interested in making games without worrying about how they’re rendered.
Thus, MVC defines a very useful design pattern for game development; the game itself (the model) is an entity completely unrelated to what the player actually sees and does, instead reacting to player inputs through a separately-defined controller, and showing the results to the player through a separately-defined view. By sanctioning these elements in such a manner, game development can be reduced to its basest form, and the controls and graphics can be abstracted out, making iterative development even more convenient for testing ideas.
A. Horner