   2D Sprite Class Inheritence
  I was working on a 2D sprite class for my game in C++ in which I was going to have a class derived from that would be animated sprites. When I broke the classes down logically in my mind though I realized a singular sprite is just basically an animated sprite class with one frame of animation. But, maybe there's a flaw in my logic. So, I was wondering does it make more sense to create a base sprite class with a derived animated sprite class or vice versa with the sprite class an animated one with one frame? Thanks.   
  To me it seems odd to derive the regular sprite from the animated one. I'm not sure I'd do it the other way around either -- the risk is that the animated sprite class will carry around unused garbage inherited from the sprite class. A good rule of C++ inheritance is this: use inheritance for flexibility, not for code reuse. It might be appropriate to create an abstract base class with the public APIs you need to expose and have two separate classes derive from that.   ;Quote:Original post by DigiMan ShartWhen I broke the classes down logically in my mind though I realized a singular sprite is just basically an animated sprite class with one frame of animation.Sounds fair enough. So why write a separate class for non-animated sprites at all?   ;  In my game, I haveclass AnimationBase: public SCDrawableclass PlainImage: public AnimationBaseclass BlinkingImage: public PlainImageclass FadeImage: public PlainImageclass BasicRowAnimation: public AnimationBaseclass TiledAnimation: public SCDrawableThis probably isn't the simplest or most efficient design, but it works for me.Most of my classes could probably be replaced by a single super generic class, but I don't really feel like changing things.Anyway, ideally you should minimize the level of inheritance hierarchy. So instead of having an animation derive from a sprite class or vice versa, have them both inherit from an abstract interface class.   ;  In the terminology I use, a "sprite" is some kind of entity in the game world that the player can interact with -- most typically this would be NPC characters or enemies, but also includes non-background static entities like pick-ups, treasure chests, etc. A sprite owns some kind of graphical representation, and also some means of reacting or responding to stimuli, but they are not part of the sprite class itself.When it comes to graphical representation I would tend to agree that a static graphic entity is just an animation with a single frame, and that an animation is just something which provides the correct frame based on its state. For me, this state is represented by an animation controller which is a finite state machine -- To impliment a static graphic entity, a factory method can easily create an FSM with a single node. Other simple looping or 'bouncing' animations, such as blowing grass, or the pendulum of a grandfather clock, can also be created by a simple factory method that produces a chain of nodes, edges and conditions. For more complex animations, you might produce the animation controller by parsing a definition file, but the output is still a bunch of nodes connected by edges, which are traversed based on the defined conditions.In my system, behavior (movement, interaction, AI) works in a similar maner. Even the playable characters work by the same system, and are simply wired up to a behavior controller which takes input from the player.You can impliment this as more of a data-driven system, as I have, or you could impliment these controllers as a shallow class heirarchy. The important thing is to place such abstractions at the correct level -- for many people, their 'sprite' classes tend to have too many responsibilities (for example having both behavior and animation responsibilites as a part of the sprite class hierarchy itself.) -- This tends to lead towards one of two poor designs -- either the sprite class hierarchy becomes large (and usually deep) or is expressed through multiple-inheritance, or differences in behavior are expressed by conditional statements or switches. The system is much more flexible when animation is animation and behavior is behavior and 'sprites' just tie them together loosely.   