Separating game logic from animation

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.