Game objects & sprites: has-a or is-a?
Author
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 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.
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.
I do an is-a
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.
->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.
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-
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-
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?
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.
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.
Author
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
- carb
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
