Take the 2-minute tour ×

For example, say you want a character animation and a health bar animation. Since these require different algorithms, should they be in the same class?

They both re-use some of the same code but having them both in one class for me requires MANY parameters to be sent in upon instance creation.

This could just be a lack of Object-Orientation understanding on my part.

I'm no sure what you would call these different "types", possibly static and moving animations. I am sure there are plenty more. I just would like to know best practices when it comes to this type of thing.


share|improve this question

1 Answer 1

up vote 8 down vote accepted

Fundamentally, animation is the changing of a set of properties over time.

Animating a health bar rectangle is just changing the width of the rectangle (or maybe the height) over time, whereas animating an on-screen 2D character is basically changing the image used for its sprite as well as its position over time.

It's certainly possible to generalize an animation class as a container of transformations of properties (sometimes called keyframes) that are applied at some time offset. Complete generalization -- the ability to animate any property on any kind of target object -- may be overkill for your needs. WPF has an animation component, and CoreAnimation is also something you may be interested in looking at -- although they are both so generalized that they can be cumbersome, so be wary.

I would encourage you to arrive at a design that does not have one class per overall animation type, if possible. At least trend towards having as few as possible and sharing code. The best thing for you to do is probably figure out which kinds of animations you want to support in your code, and what actually has to change on your objects to make those animations happen, and then build a system that can cleanly change those types of properties over time. That will serve as a decent baseline.

share|improve this answer

Your Answer


