Jump to content
  • Advertisement
Sign in to follow this  
DigiMan Shart

2D Sprite Class Inheritence

This topic is 3170 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by DigiMan Shart
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.

Sounds fair enough. So why write a separate class for non-animated sprites at all?

Share this post


Link to post
Share on other sites
In my game, I have

class AnimationBase: public SCDrawable
class PlainImage: public AnimationBase
class BlinkingImage: public PlainImage
class FadeImage: public PlainImage
class BasicRowAnimation: public AnimationBase
class TiledAnimation: public SCDrawable

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!