开发者

What's the best way to have a variable be accessible from anywhere in your program?

开发者 https://www.devze.com 2023-02-13 10:44 出处:网络
I\'m making a game right now and pretty much everything has its own class. The main classes I feel that I have a problem with are my \'Level\' and \'Object\' class. The level class contains images to

I'm making a game right now and pretty much everything has its own class. The main classes I feel that I have a problem with are my 'Level' and 'Object' class. The level class contains images to every image in the level, and the Object clas开发者_JAVA技巧s contains the image for each object on the screen(an object is pretty much anything: your player, an enemy, an item, etc).

The way I have it right now is that the Object class has an Image and when you create a new object, you load a new image into it. So lets say you have two enemies that use the same image, both instances of the object will separately load the image and I'll have two of the same images in memory. This seems like a really bad idea and later when my game gets more complicated it will slow it down a lot.

So what I was thinking about doing is having something like a Resource Manager class that would hold all of the images, and than each object would just ask the resource manager for the image it needs. That way it would only store each image once and save some space.

I could probably easily do this with a static variable in the Object class, but since the Level class also needs to use images it would also need access to the Resource Manager. Would it be best to send a pointer to a resource manager to each instance of an object/level(or any other class I later make that would need it) and access it that way? Or would there be a better way to do this?


You should usually avoid "making variables accessible from anywhere" - see here for why.

In your case, that means it's a bad idea to make the ResourceManager accessible from everywhere. I suggest you do as you say in the post - have every game object keep a pointer to the resource manager.

In the future it may turn out your game objects need to know about other core objects as well. For example your game object may need to call methods on a central game state. Then it makes sense to create a core class like this:

class Core {  
   public:
   ...
   ResourceManager& resourceManager();
   GameState& currentGame();
   // and so on
};

And your base GameObject class keep a pointer to just the core. Then you can create game objects like this:

Core core; // performs some initialization
core.startGame();
Enemy enemy(&core); // it's easy to pass the core to the game object

Have the base GameObject class require a Core& in its constructor, and provide a protected Core& GameObject::core() function.


Such problems are generally solved with the singleton pattern. Make sure to review the various issues that pattern has before applying any particular version of it.


I think i would do it this way:

1) Have a resource manager class responsible for loading everything you need.

2) Each object (image or anything else) has an associated string, in order to be able to do something like :

manager->setResource("levelImage");

A registerResource could be used, a freeResource, or whatever else you like.

This way you can easily access everything you need i think :)


I would do this using the singleton pattern. I usually create a generic singleton class that I subclass later. Something like this:

template<class Derived>
    class Singleton
    {

        public:

            static Derived& instance();

        protected:

            Singleton() {};


        private:

            Singleton(const Singleton&) {};

            Singleton& operator=(const Singleton&) { return *this; };

        private:

            static std::auto_ptr<Derived> _instance;
    };

Then the resource class can do:

class ResourceManager : public Singleton<ResourceManager>
{

    public:

        friend class Singleton<ResourceManager>;

    protected:

        ResourceManager() {};
};
0

精彩评论

暂无评论...
验证码 换一张
取 消