Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.)

share|improve this question
add comment

1 Answer

up vote 8 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

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.