Sign in to follow this  
chadsxe

I need some advice on a few OOP design issues I am working on...

Recommended Posts

chadsxe    146
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

Share this post


Link to post
Share on other sites
linternet    344
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?

Share this post


Link to post
Share on other sites
chadsxe    146
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?

Share this post


Link to post
Share on other sites
ToohrVyk    1595
If the character needs to play sounds, then it would make sense to give it an audio object for that purpose.

However, playing sounds would not be part of the interface of the character (you would not, for instance, have a character.playsound() method).

Share this post


Link to post
Share on other sites
chadsxe    146
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]

Share this post


Link to post
Share on other sites
chadsxe    146
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?

Share this post


Link to post
Share on other sites
rdansie    114
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.

Share this post


Link to post
Share on other sites
linternet    344
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 pain

Character::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 :).

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