How to represent a game character in code?

Question

In a previous game I wrote I had a game character class. This class tracked the location, velocity, and a set of states. Except the states were tied very close to the animation. Each state would have a list of buttons that can transition it other states, and an animation that would go with that state (you could also do per-frame animation state changes, if you wanted to do something like have a very specifically timed punch or something). All of the collision data for the character was done on a per animation-frame basis. This was done for a fighting game, so it seemed necessary at the time to have the animation and collision tied so closely to the character state.

But the programmer in me feels like this is mixing responsibilities. And now I'm making a game engine that I want to be a little bit more generic than that. How do you typically organize the structures relating to the characters, how they're drawn, how they interact with each other and the world, etc?

I realize this is sort of a vague question that depends on the type of game I want to make, but I think seeing how other people handle this would be useful.

(and if it matters, this is all for a 2D game.)

Answer 1

If the game behavior and the animation are closely related - as they are in fighting games - this is not necessarily mixing responsibilities.

As munificent said in Why are MVC & TDD not employed more in game architecture?, In a game, [model and view] are much closer to each other. The game world (model) is typically a set of entities positioned in some virtual space. The game view is also a set of entities positioned in some virtual space... The end result is that the line between model and view in a game would be arbitrary and not helpful: you'd end up duplicating a lot of state between them.

In other words, if a purported abstraction isn't helping parcel responsibility and improve maintainability, it's not abstraction, it's just a division.

As to how I'd make a game engine that supported any model I needed - whether it's a closely tying animation and physics bits, or a total separation of object interaction and renderer, or both for different things in the same game - I'll give the standard answer. Evolve your hierarchy with component-based entities.