Model View Controller (MVC) Game Engine
The Model View Controller (MVC) pattern has been used with great success in business software development for years. Despite this, it has never fully been picked up by the games industry. Today I’m going to discuss why the MVC pattern is perfect for game development.
Introduction
The Model View Controller pattern isolates gameplay logic from input and rendering. This “Separation of Concerns” allows each layer to be developed, tested and maintained independently. Graphics programmers work solely on rendering, gameplay programmers or designers work on gameplay and whoever’s left can work on input.
Model – Gameplay (game entities, eg. Player, Sword)
View – Rendering
Controller – Input and non-gameplay flow (menu’s etc)
The controller takes input from the player and changes the model. The controller then passes the model (and any other relevant information) to the view to be rendered.
Advantages
Cleaner Code. Large teams can work independently on each layer of the application without conflict. Clear interfaces are used to define communication across layer boundaries. As the engine grows, this separation of concerns helps to minimize complexity.
Better Cross Platform Support. Gameplay is separate and not reliant on platform specific technology. Rendering and input (both heavily platform specific) are separate and can easily be changed.
Decoupled Rendering. In most engines the game world and renderer are tightly coupled. MVC decouples the game world (and input) from the rendering. Rather than calling “Render” of each game entity the rendering system uses the model when rendering. This also simplifies the process of adding multi-threaded support to the game or renderer.
I’ve used this technique in my latest engine and it feels so much more natural. Rather than blurring the line between gameplay and rendering they are distinct and the renderer is responsible for bringing them together.
Scripting/Designers. All changes made to the model by the controller are through a known interface. This interface can be exposed to designers/modders through a scripting language giving them greater flexibility and control.
Conclusion
I won’t go into implementation details right now. If anyone is interested, I’ll put together a blog on implementation and look at releasing the MVC framework I created in XNA. Let me know your thoughts, where you see there might be problems and if you’re interested in me discussing this further.
Could you tell us what are the other patterns which are widely used in game development.
guptan-
About the only one I’ve seen used consistently is Singleton. This is usually used for global access to subsystems such as rendering or input. Other candidates I’ve seen around the place include:
Factory – great for multiplayer games, all object creation goes through a single point
Object Pool – for pooling small short-lived objects
Proxy – For some networking stuff
I managed a rough approximation of MVC for Taboo Snaps and I was so, so glad I did. It really works. Even on its own merits it’s useful but when we port it to iPhone it will be a saviour.
I did however use a liberal interpretation as suggested by my patterns book and often combined the viewer and controller in the same class, as the distinction can be a bit fuzzy IMO. Or I am just sloppy.
I used Factory a bit. I used the Event Dispatcher class in Flash heavily, so Models never had pointers to Views. I used Iterator a lot (a kind of foolproof array accessor). I also really got into typing with interfaces instead of objects, as touted by the Head First book I link to below.
I mention a couple design pattern books I found useful at this blog post:
http://www.digitalcream.com.au/blog/game-coding/love-actionscript-3-coding-programming-books/
I’m several hundred levels below Dools in programming chops– like, if he is a Frost Giant I am a… hm… kobold would be too humble… a hobgoblin, I guess. But even so I found that using good object-oriented principles and patterns was really useful, and hopefully I am learning discipline from the start.
While learning Ruby On Rails I was really digging the whole MVC model and how it would apply to games. I’ve picked up bits and pieces of it for my own stuff but not to it’s full conclusion. I typically stick to the Component/Aggregation Pattern (which has similar traits to MVC).
It’s discussed in:
Game Programming Gems 6: http://www.gamedev.net/columns/books/bookdetails.asp?productid=584
Game Architect: http://gamearchitect.net/2008/06/01/an-anatomy-of-despair-aggregation-over-inheritance/
XNA even uses it to a certain extent with it’s ‘GameComponents’ classes for the Game class. Garage Games takes it further in their later Torque Engine SKUs.
The advantages you listed pretty much apply across the board to any type of context (Business, Games, etc). I’m curious if you ran into any disadvantages while working with it, and if you had any game specific advantages. For example, a game mechanic where wearing a cool hat was spaghetti code but the MVC with different Views helped implement that mechanic (trite example I know).
I’ve run into disadvantages in the Component-pattern but they tended to still be more elegant than the strict inheritance model.
Alex O-
Thanks for the info. Torque is on my todo list of engines to look into at the moment.
I’ve played with GameComponents in XNA and I think they’re a great idea, but don’t take it quite far enough. Having a full MVC based engine would go a long way to simplifying XNA and engines in general.
As for disadvantages, the main one is convincing people it’s a good idea. It’s so different from every engine I’ve used in the past I have a hard time convincing people it’s a viable solution.
The main concern I have is specific implementation using MVC. The pure model approach might cause issues if done badly. Animation is a great example:
If done badly, the animation data will be split over model, controller and view and become a real mess. Particularly if you’re using a 3rd party animation system it will be hard to split the concerns up correctly.
However if done right, it can be extremely powerful. The model simply stores when an animation has begun, that’s it. This simplifies netcode and general coding of the model. The animation system (in the view) then uses this information to render the model at a given frame in the animation. The animation system can easily be changed without affecting the model. Gameplay programmers don’t need to think about animation and different platforms could ignore it entirely.
Thanks for the reply. That is really interesting. I would have never thought to simply put ‘start/stop’ in the model and have the view contain the actual animation data. It makes sense from a networking perspective though :]. I would’ve ended up (like you said) with animation data in at least the model and the view.
I’m definitely going to explore the possibility of a more strict MVC model in future games.
Alex O-
I’m exploring the possiblities of a Unified Scripting Language (one language for all platforms and engines) and having an MVC based game engine would be perfect for this. The entire model would be written in the unified scripting language making cross-platform development extremely easy. Just change the view and controller to go to a new platform.
I’m going to investigate MVC further as well and will report on my findings.
Thanks for this, there are so few articles out there on game programming with mvc or composition.
I would be very interested in hearing how MVC can be applied to a game.
I have seen MVC do wonders for web developers (like PHP symfony / ASP.NET MVC) and having an incoming request processed by a controller which modifies the model or retrieves data from it and then letting a view present the results to the user is very natural and logical.
But I can’t think of a way to apply MVC to a game. In my mind, the view (= rendering, audio control) would have to constantly and directly contact the model (breaking the concept of reusing views in different controllers).
Getting a view to the point where it could render a game scene without knowing about the actual entities (in other words, all it renders is received from the controller in anonymous property bags) sounds impractical. Especially if the controller needs to do this repackaging on a frame-by-frame basis (maybe being clever and using frame coherence to keep the property bags is they key here?)
Cygon-
I’ll give you a brief overview of how my MVC engine works:
Controller
This handles the input and flow of the game logic. This is akin to the states your game can be in. My primary two controllers are main menu controller and an in-game controller.
They are responsible for converting input into something the game world (model) can understand. Eg “Create unit x at base y”.
Model
This handles all game logic. It has nothing to do with input, rendering or networking. It is a pure view into the game world. Designers need only worry about what’s in the model.
View
The view handles rendering of the model. Unlike what you said, the view DOES know about the model. The has read-only access to the model. This model can be anything. For my main menu it’s a list of UI controls the controller has built. For the in game view, it’s the game world.
To keep things clean and consistent I use Interfaces in most places. Rather than “reusing views in different controllers” what is more important is “having multiple views on a single controller”. For example there might be a 2D and a 3D view of the game world.
Coming from an enterprise applications background, especially web, I have a lot of experience in MVC. I am just beginning game programming, and because of my background, the first thing I considered is the architecture.
I’ve looked at the game/component approach, and I agree that it doesn’t seem like quite enough.
Though, I also don’t think MVC by itself is enough either..
I think adding more abstraction to the architecture could be more beneficial. I think a domain-driven design approach to game programming, with a more complicated/abstracted architecture would lend itself very well to game programming.
My proposed architecture is something similiar to the following (based on MVC and domain driven design)
Application Layer
- Contains application.interfaces, and application.services
all services use interfaces, generally hold logic for animation, and things that the models/entities have to do
Domain Layer
- Domain.Model contains physical entities
- Domain.Repositories contains repository interfaces for accessing Models from the db
Infrastructure layer
- infrastructure.orm if you want an ORM, put it here (ex. EF)
- infrastructure.repositories – concrete implementation of interfaces from domain.repositories
IOC layer
- Inversion of control if want to use it (would be interesting to see how it works with game dev.) this architecture lends itself to using IOC containers and dependancy injection
Test Layer
- unit tests
Controllers Layer
- access the models, pass data to ui layer (views)
UI Layer
- UI stuff
Again, I am just starting game dev, and I haven’t tried any of this in the context of game dev yet, however I plan on trying it. Anyone have experience with anything similar and can offer some feedback?
Hi, good to know I’m not alone in this. I’m programming an MVC game engine using Python for prototyping. I wrote some posts with specific pseudocode in my blog, but I’m afaid it’s in spanish.
One problem I face is that there is some natural encapsulation of objects that need to be scattered through M, V an C. For example, it is natural to have a spaseship as an object, however, the spaceship has a model (it is part of the physics engine), a view (a mesh or sprite that could be view dependant) and a controller (in my engine some AIs are part of the controller since they can replace users easily).
How do you handle this problem in your game engine? Do you know of an open source example I can have a look at?
Late to the party!
I found this to be a very interesting read:
http://www.gamasutra.com/features/20050414/rouwe_01.shtml
It is Shell Shock, ‘nam 67 (an medal of honor type fps) made with MVC.
They touch on animation as a sticky point for them as well, because for some games the animation is NOT just a view concern, but it can change the model as well due to shifting bounding boxes or detailed collision requirements.
I think in most MVC use cases there are going to be some fuzzy areas where you have to compromise the principles due to the harsh reality, heh.
I have not done ANY MVC work yet myself, but I am drawing out different UML designs right now to see what structure will work best for me.
I can already see that the division will be the only thing that will keep me sane as it is a multiplayer game with a polling engine where the game pieces could be local users, simple ai, or remote players. Being able to manage the difference by just making multiple controllers where needed is going to be very nice.
My first go at this I had a lot of repeated code for local and remote player objects. Now the difference is just what the controller does with the input which can either be polling responses or clicks being forwarded from the view. I have never been happier to throw old code away, heh.
[...] your concerns. A big part of why MVC works so well for a game engine is that it keeps the obvious concerns (e.g. gameplay vs. rendering) [...]