Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For non-game applications the model-view-controller pattern is typical where data, logic, and visuals are separated. But for a game how would you architect the game logic and the animation system in this way?

The gut instinct is to just not think about this and jam the 3d model and its animations into the Unit class where there is also the unit attack logic. And then to just to intermix the code that runs the attack logic with the attack animation. But suppose you wanted to keep these animations separated. What kind of design pattern would you use?

Perhaps a way of testing a design to see if its good is to see if it allows reasonably easy replacement. Imagine replacing the the 3d polygonal animation system with a voxel animation system. What kind of design pattern and game architecture would make this easy? Obviously just intermixing the code that runs the attack logic with the attack animation would make this hard.

share|improve this question
up vote 4 down vote accepted

You should strive for data-driven animations.

I especially advise that you do a bit of research around Blend Trees, they're the most powerful and flexible design I've seen so far. Read this for a few references.

share|improve this answer

Well you wouldn't really do an mvc design directly in a game as games generally have a specific set of requirements, content, and functionality. In terms of keeping thing separate, you could have class based animations for example, like all humans walk so that can be a bone animation. Then from there, each model/unit would have various actions that are tied to a specific animation group. But just remember, things in games are often scripted and most games choose speed over flexibility. See how something like UDK does it

share|improve this answer
Even non-game applications have a "specific set of requirements, content and functionality." :) – David Lively May 29 '12 at 16:39
yes, but they're designed to work with multiple sets of data (thats generally the argument for mvc) however games have generally a single purpose and everything is made specifically for that – CobaltHex May 29 '12 at 16:50

I wouldn't necessarily use an MVC design for individual units (at my company we do take that approach with the UI) but rather a component architecture. You can look up "component design" in other questions, but the gist is that Unit is comprised of a collection of loosely coupled components, of which AIComponent and AnimatedModelComponent are just two.

share|improve this answer

A strict MVC approach is generally geared towards GUI applications so it's not always very applicable to games. However there is still much benefit in separating logic from presentation where possible. At the very least the renderable part and the animations should be stored as a subobject of the unit in your game, so that the rest of the unit code isn't mixed in with the graphics. Perhaps a better approach is to have the renderable object hold a reference to the unit so that the animation system can examine the unit's current state and properties to produce the correct visuals. You may find an Observer pattern useful here, so that changes to the unit can be immediately picked up by the rendering side, without the unit needing to know anything about rendering specifics.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.