Sign in to follow this  

tiles vs sprites : inheritance?

This topic is 4594 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

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.

Share this post


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

Share this post


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

Share this post


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


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

This topic is 4594 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this