MVC in Games

In the game I’m currently working on, it appears that I’m slowly drifting
towards a design that’s a close resemblance of the Model-View-Controller
(MVC) pattern, despite originally rejecting the idea because I
believed it would require my game world to expose too much of its
internal data just so the view could keep track of things.

Because I originally believed to be building a very simple game with very
simple logic, I chose a design that would create a nice, non-fractured
interface to the world so I would have an easier time building the AI
and player controls on top of it:

In this design, everything could access everything else – a monolithic
world component where the public interface was well encapsulated,
but that allowed the implementation to take the most direct path possible.

"Everything could access everything else" doesn’t mean my
objects directly modified each other’s state, but it meant, for example, that
a building had a reference to the island it was placed on and that it could
call an internal method in the Island class to inform it when
the building was destroyed or moved.

A full design, in contrast, would give the buildings an interface through which
they determined properties about the ground (is it too rough? underwater?) and
some events so its owner would know when the building was destroyed.

If I had only taken game logic into account, this all would have worked out
very well. But there were some things that added a lot of complexity…

Lessons Learned: Complexity

Back when I created above design, XNA had just reached its 1.0 release.
One still had to cope with lost devices (that means at any random point,
all your graphics resources like VertexBuffers
or Texture2Ds
would go bang and you had to dispose and recreate them, something
that was later hidden from the programmer with XNA
2.0’s virtualized GraphicsDevice), so I did the only sane thing
I could do and built a layer for the visuals which would hide that little
inconvenience from the game logic (you can see it at the bottom of my UML
diagram, the Asset class).

The flaw that made it all come down was that the game logic objects
owned the Assets. And because I wanted to be able
to unit test my game logic without graphics resources, I designed my
Building, Unit, etc. classes to make
the Asset optional.

Assets were created through the AssetManager.
But how would a Unit or Building obtain a reference
to the AssetManager? Simple, I thought: the World
owns an AssetManager. As soon as a Unit or
Building is added to the World, it would set up
its Assets.

Can you smell the problem already? Let’s see what logic each building has
to incorporate now, just to function properly within the system I set up:

A building can be constructed and added to an island that is part of
a world with an AssetManager.

A building can be constructed and added to an island that is part of
a world with no AssetManager

A building can be constructed and added to an island that does not
belong to a world. The island can then be added to a world with
an AssetManager

A building can be constructed and added to an island that does not
belong to a world. The island can then be added to a world without
an AssetManager

Now duplicate these 4 cases for when the AssetManager is
added to the world after the islands and buildings have been created.
And get everything to works right in reverse: the building could be
removed from the island again, the island could be removed from the world
and the world could loose its AssetManager (in order to
avoid imposing a destruction order on the game’s shutdown process)

The result is that each game logic object in the nice tree I built
needs to be informed of any ownership changes to its parent, its
parent’s parent and so on. And that’s what finally kicked this design
out of the door for me.

MVC to the Rescue

To get rid of this complexity, I am currently removing all graphics code
from my game logic classes and writing external Renderer
classes that contain the graphics code.

The game objects will have to provide additional detail, for example,
I’m not sure yet how I handle turrets: they will need to expose their
orientation, elevation and either hand over the bullets they’re spewing
into the air to another manager or (if I decide to make bullets
instantaneous hits/misses) provide at least a list of vectors of
the bullets that were fired in the last Update() cycle
so the renderer can draw the appropriate streaks.

As it turns out, this more an more resembles the MVC pattern:

I was a bit skeptical as to whether MVC makes any sense as a tool in
game programming (for example, see my reply on Doolwind’s blog post
"Model
View Controller (MVC) Game Engine"), but now I believe that
it’s generally a good idea to design the game logic without mixing any
graphics code into it. I would select a radically different design for
a game with a larger scale, but even then, keeping the graphics code
separate from the game logic code seems to be a good idea.

All my problems are nails and MVC is my hammer!

That’s of course not what I’m proclaiming here, but if this turns out
well, MVC will probably my preferred architecture for future games 🙂