Jump to content
  • Advertisement
Sign in to follow this  
bartiss

static object

This topic is 4220 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm trying to add sound system to a quite big hierarchy tree of objects. I've created a cSoundSystem class and I want all the game objects to use it. My current approach is: 1. Create cSoundSytem object dynamically in the app class. 2. Set a global pointer to the sound system. 3. Use extern in the game root object to get the sound system pointer. Well, it works. But I don't like this solution. I know it's possible to make it like this: 1. Create single instance of cSoundSystem 2. Access it through cSoundSystem:: from any object knowing the type How do you do this? And am I right to try it?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
make sure to do a search at gamedev/wikipedia/google for "singleton"

Share this post


Link to post
Share on other sites
Quote:
Original post by bartiss
How do you do this? And am I right to try it?
Many will tell you that singletons are nothing more than 'glorified globals', and should be avoided in most (perhaps all) cases. They can solve the problem of initialization order (or not, depending on how you implement them), but otherwise they have many of the same drawbacks as globals (strong coupling, excessive dependencies, etc.). Some even go so far as to call the singleton an antipattern.

A good question to ask yourself is, who really needs to know about (and have access to) the sound system? When an object is available as a singleton, it becomes all too easy to just grab the instance and do things 'where it's convenient' rather than where it 'should be done'. For example, game objects end up playing sounds directly via the manager rather than, say, sending a message that a sound should be played.

I'm not saying these problems are easy to solve, because they aren't! Also, I'm no software engineer, so take the above with a grain of salt. In any case, I'd recommend taking the AP's advice and doing a search on the term 'singleton', as there are many articles and forum threads on the topic to be found online.

Share this post


Link to post
Share on other sites
I would recommend reading up on them regardless, and trying them out for yourself. A little extra knowledge never hurts, and if you're planning on working professionally in the game industry, they *are* used at many studios. So even if you don't like them, or they don't work for you in this instance, at least you will know how they work, and what problem they solve.

Bottom-line is if you try it, and find you don't like it -- don't use it.

Cheers.

Share this post


Link to post
Share on other sites
Ideally, since the App creates a cSoundSystem, it should not be global. Making it global allows the possibility of accessing it before it has been created.1 The App should pass a reference to any class it controls that might need to access the cSoundSystem. Classes external to the App would access the cSoundSystem through the App or query the App for a reference to the cSoundSystem.

In practical terms, such a system is can be very inconvenient. It results in lots of parameters and pointers, leading people to use globals -- giving up some correctness, robustness, and maintainability for the sake of convenience.

1 Singleton prevents this, but that feature is usually overlooked.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!