Posted on September 24, 2009 by Doolwind

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.