From the top... I have a "Game.h" class that runs my game. I also have a Sprite.h class in which I can create sprite objects. My Game.h object makes calls to my Sprite objects. My Sprite Objects make calls to various API (in this case SDL) classes, and logic classes. Now, in my head it makes sense for a sprite object to encompass everything that a sprite would be capable of. I.e. Move, determine if collision has occured, etc. This is works out well and I am very happy with my framwork to this point. My concerns come with my implemnatation of my Audio class. Obviosuly my Audio object will handle the mid/low level stuff like loading, playing, etc.. My question to you is would it be smart to hold audio data (variables) inside my Sprite objects. If you look at it from a real world perspective a Sprite sould be able to talk for itself....i.e. spriteObj.PlaySound(); But I am just not sure if is good design. If I don't hold these variables inside my Sprite Object then I would be throwing Audio Object calls around everywhere...i.e. audioObj.Playsound(); Just looking for some insight Regards Chad

Personally I would abstract even further. What's your definition (english wise, not code) of a sprite?

To me, a sprite is an animation. It shouldn't move or collide with anything. It's your character that moves, collides and makes noises. A character (or whatever you want to call it) might contain a sprite object for rendering and an audio object for making noises but why the sprite itself?

Hmm that makes sense... Your definition fits my definition of what I was considering a sprite. So, lets say I did abstract deeper and I made a Character class. From there would it makes more sense to to have audio variables a part of the character class?

class Audio{
public:
void load();
void play();
};

class Character{
public:
Audio charAudio;
};

Hows this?

so it would not make sense to do soemthing like

if character hits wall
characterObj.Playsound(OUCH_SOUND);

from there it sould go

Character::Playsound(const char* filename){
audioObj.playSoundEffect(filename);
}


or would it?

[Edited by - chadsxe on May 7, 2007 11:23:27 AM]

Quote:Original post by rdansie
class Audio{
public:
void load();
void play();
};

class Character{
public:
Audio charAudio;
};

Hows this?

This would work but would we not be creating to many audioObjs (one for every new character obj). What is the purpose if we can just create one AudioObj and pass by memember reference. This would save space, no?

Quote:Original post by chadsxe
This would work but would we not be creating to many audioObjs (one for every new character obj). What is the purpose if we can just create one AudioObj and pass by memember reference. This would save space, no?

No when several instances of a class are created they dont create a copy of the methods for each instance. They will all share the same code. The only extra space would be for any data members within the audio class.

Edit:
Alternatively you could create a single audio object and have a reference to it from each character object or just doing it the way you specified would work fine aswell.

Quote:Original post by chadsxe
so it would not make sense to do soemthing like

if character hits wall
characterObj.Playsound(OUCH_SOUND);

from there it sould go

Character::Playsound(const char* filename){
audioObj.playSoundEffect(filename);
}


or would it?

Well, characters don't "play sounds". Characters scream, laugh, speak, cry etc... you could get very specific like:

if character hits the wall     characterObj.Scream();    // scream out in painCharacter::Scream(){     m_audioObj.playSoundEffect(SCREAM); }

or, you could do something more generic, like:

if character hits the wall     characterObj.Express (PAIN);Character::Express (int emotion){    switch (emotion)    {    case PAIN:         m_spriteObj.renderAnimation (WINCE);         m_audioObj.playSoundEffect (SCREAM);         break;    case CONTEMPT:         this->Speak ("You're pathetic");         break;    }}

The "concept" is to think in terms of the object you're creating, what does it needd to do, and what makes it unique.

For example, pretty much all audio objects need to be able to play so that method makes sense in AudioObject. However, a music piece may need to pause and resume where a sound effect might not need that, so you might want classes for MusicTheme and SoundEffect, both of which inherit from AudioObject but with different methods.

PS: I'm only writing this because you asked about OO desgin. Honestly you can go insane designing your classes still be capable of a better academic OO design (you can certainly do far better than the pseudo-code I wrote). At some point it really does get counterproductive.

Practically speaking, however, if your comfortable with your design and it fits the scope of your project don't spend too much time working on a "perfect desgin" - the player certainly doesn't give a crap :).