next »

[Hajo]

An object might also have a list of sprites, or might change the visual appearance during its lifetime.

Both cases go well with a "has a" relation.

"Is a" should be restricted to things that just narrow down the functionality or domain of the parent class/object. Which is not the case for a sprite and an game object. Quite often, even in that case, you'll find "is a" relations to be very strict and inflexible, making changes difficult in later stages of the project. Delegation is a pattern that can help there.

So "has a" for sure IMO for the sprite <-> object case.

[Michelle Disraeli]

An object might also have a list of sprites, or might change the visual appearance during its lifetime.

I'm actually thinking that perhaps it is more important that an object might not be a sprite - there are many great uses for invisible objects in a game world.

This hence automatically forces a has-a relationship, rather than an is-a (and all you need do is have either null checks, or a stub display class)

[Gary the Llama]

Sorry to bump an old thread, but I thought it would be better than starting a completely new thread.

Does anyone have an example of the entity/sprite relationship when using the D3DXSprite interface? Right now I believe that my Entity class would not contain a reference to the D3DXSprite interface, since I only need one D3DXSprite object for the whole game. And then I would just have a vector<entity> and loop through that for rendering.

Any example code would be great.