Sign in to follow this  
carb

Game objects & sprites: has-a or is-a?

Recommended Posts

Hey all, I was just curious how many people represent their visible game objects as subclasses of a sprite object, and how many people have their game objects contain a sprite object. I'm having difficulty coming to a decision myself. What are the pros and cons? - carb

Share this post


Link to post
Share on other sites
I have a class called ObjectLayer that all map objects (sprites, static objects like wheelbarrows, and animated objects like trees) inherit from. I keep a list of all my objects, sorted by map position. When I begin drawing map objects, I draw them from top to bottom, left to right.


Blargh, I don't have time to go in-depth right now because I have to get ready for work, but maybe I'll think of a pros/cons list tonight.

Share this post


Link to post
Share on other sites
I do an is-a

->Character->...
Object->Sprite-
->Item->...


identification of actual type comes from our implementation of an 'InstanceOf' function, that allows us to ask if a given object is an instance of somthing.

as for the pros and cons *shrug*, not sure since i've never tried the other way.

Share this post


Link to post
Share on other sites
Clearly a case of has-a:

Reason 1: It is unlikely that absolutely all of your game objects are always associated with exactly one sprite for their whole lifetime. Maybe some don't have a visual representation, maybe some are made up of multiple sprites ?

Reason 2: What if you needed an AnimatedSprite class ? Using has-a and a (smart) pointer, you can assign an AnimatedSprite, derived from Sprite, to the game object without the need to create a second game object which derives from AnimatedSprite (which could be quite a bugger)

Reason 3: Multiple game object are likely to share the same sprite. Using is-a, each game object would have its own copy of the sprite. Not very memory efficient and quite ugly.

There are even more reasons why this is not a case of is-a, just think about what you'll be doing with those objects.

-Markus-

Share this post


Link to post
Share on other sites
Quote:
Original post by Cygon
Clearly a case of has-a:
...

-Markus-


Yes, excellent examples right there. #3 being the main reason I do has-a, so 10,000 game characters can reference the same sprite if I want to.

Just seems bad design to directly integrate a game object with it's visual representation when the visual representation could vary wildly and possibly require unique specialized sprite classes, or what if you had a character made of a particle system or something your sprite class doesn't do?

Share this post


Link to post
Share on other sites
well it all depends in how you define a 'sprite'

as far as we are concerned, a sprite is a single object in the game world, a character an item, etc.

and any sprite has the ability to be animated or moved, etc.

a sprite need not have an image associated with them,

or a sprite can have it's drawing overriden to allow for a more complex system of images or effects to be performened (a derived sprite) for particles and such.

again, it's all in how you define 'sprite'

so i dont think it is as 'matter of fact' as you say =)

if you define a sprite as being, the actual image data for a game object,
then yes that image data should be 'shared' via is has-a type system.

however, we define a sprite as being, the game object itself, and our image data comes from an ImageSet object.

Share this post


Link to post
Share on other sites
Well, I define a sprite as being the onscreen representation of a game object. It has screen coordinates, texture data, etc. I don't "share" sprites - I do, however, share the texture data using a resource manager. I suppose that sounds like I favor a "is-a" relationship, but it's actually the other way around.

- carb

Share this post


Link to post
Share on other sites
Neither.

My game objects have absolutely no idea how they're represented by the UI. The UI largely doesn't care about what it's displaying beyond such and such texture at such and such screen coordinates.

The only thing I do is have an [optional] type/pointer pair held by UI objects which is passed as a parameter to events occasionally.

The main reason is because my game is multiplayer. Game objects exist on the server, and the UI objects don't.

Share this post


Link to post
Share on other sites
Quote:
Original post by carb
Hey all,

I was just curious how many people represent their visible game objects as subclasses of a sprite object, and how many people have their game objects contain a sprite object. I'm having difficulty coming to a decision myself.

What are the pros and cons?

- carb


I use a Sprite class which has methods for displaying and animating sprites. It stores the total frame count, frame delay, etc. I then have an Item class which contains a list of pointers to Sprite objects (using an std::vector). Whenever I need to "attach" a sprite/animation to an object in my game it's as simple as object->sprite_list->push_back(sprite). Finally, I have an Entity class which inherits from the Item class, but also specifies some additional properties only applicable to living things.

Basically, each sprite/animation in my game is stored as a Sprite object, and then every Item and Entity in my game has access to those Sprite objects once they're added to the particular Items'/Entities' list.

Share this post


Link to post
Share on other sites
Quote:
Original post by EDI
well it all depends in how you define a 'sprite'

as far as we are concerned, a sprite is a single object in the game world, a character an item, etc.

and any sprite has the ability to be animated or moved, etc.

a sprite need not have an image associated with them,

or a sprite can have it's drawing overriden to allow for a more complex system of images or effects to be performened (a derived sprite) for particles and such.

again, it's all in how you define 'sprite'

so i dont think it is as 'matter of fact' as you say =)

if you define a sprite as being, the actual image data for a game object,
then yes that image data should be 'shared' via is has-a type system.

however, we define a sprite as being, the game object itself, and our image data comes from an ImageSet object.


I think EDI summed it up nicely here. Unless there is an absolute definition for "sprite" somewhere (a game programmers dictionary?) it is going to depend on your own situation. If a sprite is defined as the image data then I think most people here agree it 'has-a' sprite and if a sprite is defined as an actual tangeable object then it is 'is-a' sprite. Luckily for us I don't think there really is a game programmers dictionary so our life is filled with mystery :).

Share this post


Link to post
Share on other sites
How I'm working my sprites, is I have an object that is a SpriteCache, and it contains groupings of sprites by a key.
SpriteCache["Sprite_Cache_Key"] = image;
Tis way in each of my Actor objects they just have a String that is the Sprite_Cache_Key that the object has for a sprite.

So some code would be like (in java):

public void drawTile(int cX, int cY, Graphics2D g, Sprite_Cache s, int y, int x) {
if (y % 2 == 0) {
g.drawImage((Image)s.getImage(((Tile)tiles[y][x]).cSck), 40*x +cX, 10*y-(((Tile)tiles[y][x]).height)*8+cY, null);
} else {
g.drawImage((Image)s.getImage(((Tile)tiles[y][x]).cSck), 40*x+20+cX, 10*y-(((Tile)tiles[y][x]).height)*8+cY, null);
}
}

//tiles[y][x] = tile tracking array





Is this a completely bad way to do it?

Share this post


Link to post
Share on other sites
Quote:
Original post by H_o_p_s


Is this a completely bad way to do it?


I'm no expert, so the only advice I can give is to use a number for the key. It should be faster [comparing 1-4 bytes, rather than an arbitrary sized string] (assuming java isn't smart enough to optimize the strings out for you).

Share this post


Link to post
Share on other sites
I have to say that the word sprite has graphical connotations for me...(I'd use has-a). In terms of actual definitions, it also seems to be the consensus.

In reality though I don't think your personal definition matters as long as it doesn't cause confusion...(and it's not too different from mine [evil])

Share this post


Link to post
Share on other sites

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