Video Game Classes

I have a question that sort of a matter of opinion, but I'd like to get some input. Here's what i have:
A Bitmap class, which holds all info about the bitmap;
A Sprite class; this class is made up of several bitmaps. it has several for each frame, plus masks and "under" bitmaps for erasing the sprites. This class also includes member data like speed and position.

Now, i want to make an asteroid class, which will hold data about each asteroid. Should I:
have an instance of the sprite class be a member of the asteroid class? With this be too much overhead? If i do this, the data like speed and position would not need to be included in the asteroid class, as it could be accessed like: asteroid.sprite.x. however, this seems kind of roundabout. Should i maybe put the data like position and speed into the asteroid class, and remove it from the sprite class, leaving the sprite class strictly for frames of images and such? I've included the sprite class and the bitmap class (but not the asteroid class, as i have created it yet). Please give me your thoughts and how to go about this.

thanks,
jmiller

I have been doing something similar to this.

It depends on if you want to reuse Sprite for other proejcts. If Sprite is holding all of your graphics stuff, I would include all graphics stuff in Sprite (Bitmap*, width, length, etc.) This allows for you to use Sprite later in volitile (as in short lived code) game engines.

Then in asteroid, put velocity, position, your Sprite* (saves a lot of memory if you have zillions of them on the screen,) and whatever else that makes asteroid and asteroid in the asteroid object.

Basically, by looking at it from the viewpoint of what each object should do, you can divide attributes between the two objects in a logical manner.

You could also derive Asteroid from Sprite. Can make sense, depending on what place Asteroid takes in your logical structure.

If what was placed inside of Sprite was textures, then it would not be plausable to inherit assuming that a lot asteroids were on the screen and those asteroids were al using the same set of bitmaps.

You ought to make an array of all possible textures a static member of the class and have every class instance store only an index into that array.

how well do the classes work?

Why a static member?

Say if you want to create a whole bunch of different asteroids. A static member variable can hold only one value per class, making it very limited.

I like the idea of an index to an array, though. Less pointers allow for less problems.

That's why the static member is an array.

Why not create a sprite manager?

A Sprite manager which would probably be a templated List of some sort, could take all of the Sprites, store them in a "pool." I think MFC has such an object if you are cramped for time, if you know MFC, or if your application allows for the cycles.

This way, if you want to reuse this storage structure, you can always just link it instead of hacking apart Asteroid. Plus, if you want to create textured landscapes and stuff like that, you can always just pull from the pool instead of playing with Sprites.

Now, an index to the texture would be more costly in terms of speed but it is safer than playing with pointers. Both methods have their ups and downs, but thats a preference thing right now.

Use the STL containers, not the MFC containers.

I perfer to make my own because I know how. :)

That's no reason. ;)

If you already know how then there is no reason to make one. Either you already have one or you simply use the STL ones anyway, they're probably more powerful than yours :)

Container writing is something you do when learning the language, or when you need a VERY specific container. OOP is about reusability.

I usually use specialized container structures, and the ones that I help write are for beginning C++ students.

However, I would like a source for the STL container classes if you have one. The sources that I have are for MFC or code to build your own.

Get the GNU C++ library.