tiles vs sprites : inheritance?
Author
It seems to me that in a tile engine, a tile isn't going to be really different from a sprite, except maybe the sprite will have it's own x/y position variables and the tiles' would be worked out by the engine by their position in an array.
Anyways, on to my question, which involves another part of c++ I never touched: inheritance.
Would there be any point to deriving sprites and tiles from a common class? What's the advantage behind doing it this way? It seems like the only real advantage would be the fact that if you ever wanted to have a instance that was either a tile or a sprite, but you didn't know which, you could still use the instance without knowing.
Any other reason? Thanks.
I don't see how a sprite and a tile are in any way different to the renderer. So to me, they should be the same class.
But... in reference to your question, by using inheritance, you can combine similar code into one base object. Less code means less room for errors. Less copied code means less code to change should you need to change something.
But... in reference to your question, by using inheritance, you can combine similar code into one base object. Less code means less room for errors. Less copied code means less code to change should you need to change something.
imo, sprites go in a different class. My sprites have AI and sophisticated movements; which a simple tile doesn't have.
Inhertitance is handy for different kinds of sprites; bosses, monsters, flying enemies; they all have certain things incommon.
Inhertitance is handy for different kinds of sprites; bosses, monsters, flying enemies; they all have certain things incommon.
It all depends on how you store your sprites/tiles.
A sprite is usually a "dynamic" image, consisting from a spritesheet which holds a certain set of animations(Snapshots). When the sprite is moving, these snapshots are being drawn depending on the state. Say a walking mario has 8 snapshots, and in 2 seconds, mario is fully animated, the snapshots are changed every 250ms.
Now, a tile is usually a static image(But not always).
Say that both your sprites and tiles can be animated, then yes, it's smart to take a common class. For instance, take a look at this:
That could be used both for sprites and tiles(Animated or static).
Toolmaker
A sprite is usually a "dynamic" image, consisting from a spritesheet which holds a certain set of animations(Snapshots). When the sprite is moving, these snapshots are being drawn depending on the state. Say a walking mario has 8 snapshots, and in 2 seconds, mario is fully animated, the snapshots are changed every 250ms.
Now, a tile is usually a static image(But not always).
Say that both your sprites and tiles can be animated, then yes, it's smart to take a common class. For instance, take a look at this:
class RenderObject{public: RenderObject(CBitmap *pBitmap, AnimationInfo AniInfo); void Render(CRenderInterface *pRenderer); UpdateResult Update(float fTimeDelta);protected: CBitmap *m_pBitmap; AnimationInfo m_AniInfo; int m_nAnimationState;};That could be used both for sprites and tiles(Animated or static).
Toolmaker
Quote:Original post by Marmin
imo, sprites go in a different class. My sprites have AI and sophisticated movements; which a simple tile doesn't have.
Inhertitance is handy for different kinds of sprites; bosses, monsters, flying enemies; they all have certain things incommon.
If you look at my example, I've shown how you can move similar code into 1 base class. Easier to maintain and forces the programmer to use a specific interface.
Toolmaker
Indeed, I make the distinction between "image" and "animation".
[aside: and I -don't- couple any sort of game assumptions such as AI or player control into the rendering classes, should mario suddenly change from a static image to an animation. Presentation is seperate from processing.]
[aside: and I -don't- couple any sort of game assumptions such as AI or player control into the rendering classes, should mario suddenly change from a static image to an animation. Presentation is seperate from processing.]
Inheritance is a great thing and you must come to learn its concepts before you expect to do anything masterful with object-oriented programming. Personally, I would have a sprite class derived from the tile class as you want your sprites to have more functionality then the tiles themselves. But of course you could still have them as the same objects, just handled differently.
Typically:
- An Image represents some rectangle on a sprite sheet.
- An Animation represents a sequence of Images, possibly with timing information.
- A Tile is composed from (included members - not inheritance) an Image, plus the tile's location.
- A Sprite is composed from (included members - not inheritance) an Animation, plus the sprite's location.
Not all of these concepts necessarily need to be represented as full-blown objects. You might consider the degenerate case of a one-frame Animation to do the work of an Image (and later get "animating Tiles" for free, e.g. for an effect of water waves in the background of an ocean level), and store the rectangle data with a POD struct (or borrow one already used for that purpose, e.g. SDL_Rect).
- An Image represents some rectangle on a sprite sheet.
- An Animation represents a sequence of Images, possibly with timing information.
- A Tile is composed from (included members - not inheritance) an Image, plus the tile's location.
- A Sprite is composed from (included members - not inheritance) an Animation, plus the sprite's location.
Not all of these concepts necessarily need to be represented as full-blown objects. You might consider the degenerate case of a one-frame Animation to do the work of an Image (and later get "animating Tiles" for free, e.g. for an effect of water waves in the background of an ocean level), and store the rectangle data with a POD struct (or borrow one already used for that purpose, e.g. SDL_Rect).
Inheritance comes in handy for changing things and yet not starting over. For instance, different scenes or levels in a game have a lot of common behavior. You can also put things that have the same base class but different derived classes in the same container and then check to see what's what. That's mainly what I use it for.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
