Resource Managers - Are they any good?

Question

I've seen many a time in source code, things like this [well, this is more of a pseudo C++ idea of mine]

typedef shared_ptr<Resource> ResourcePtr;// for ease  
ResourcePtr sound1 = resourceManager.Get<SoundResource>("boom.ogg");  
sound1->Play();  
ResourcePtr sprite = resourceManager.Get<Image>("sprite.png");

I was just wondering how useful a class like this was, something that:

• Loaded media files
• Stored them in memory
• Did this at the start of a level - loading screen.
• Cleaned up

Rather than having a system of:

• Resources are held by entities only, or loose.
• Responsible for own load into memory.

The first is a 'manager' as such; something I feel indicates it's wrong to use. However, it allows for something like a vector of resource names to be passed, rather than having to scramble around finding everything that needs to be loaded.

Answer 1

A good resource manager is key to how well - and how flexible - your game 'engine' is going to be.

Not only does it solve a lot of problems with low level resource management, but it also helps to ensure that resources are loaded only once, and then reused if they are already loaded.

If the resource system is abstracted well, the underlying details can wary between file system, physfs storage, sql even...

You just request a resource, and it's given to you.

No need to worry about resource IDs and stuff like that.

Duplicate resource conflict handling, etc.

Let the resource manager sort that out.

Depending on how you design it - if C++ then make friends with your scenemanaging class(es) to ensure that ownership is properly handled.

Resource pool ?

No problem.

Forgetting to release resources?

No problem.

Same interface to resources no matter where they are: memory, disk, archive, network.

No problem.

Do you want streaming?

Threading?

Let your resource management hub take care of that.

And you can rest assured that it will inform you when the resources are ready to be used.

Ogre 3D has a very flexible resource management system, but I am sure there are others 'out there'.

Answer 2

I recently wrote a resource manager which works pretty well for my case. Main features:

• Resources are requested by string ID, for example, ResourceManager::instance().getTexture("textures/player.png"). The texture ID is currently mapped straight to a file on disk, which is convenient during development, but this will later be replaced by lookup in some archive.

• The resource manager holds on to a map of IDs to resources, so it won't reload a resource that has already been loaded.

• The above call does not return a Texture object, but rather a Resource<Texture> object; the caller is expected to store the Resource<Texture> object and not the actual texture. The Resource<Texture> acts like a smart pointer to a Texture; its operator*() returns the Texture object itself. The advantage is that the actual texture can be reloaded, or unloaded, without the need of updating all clients.

• The resource manager checks periodically whether files on disk have changed, and reloads them if necessary. This allows me to modify textures or shaders and see the result without even restarting the game.

• Resources can be dependent on each other. Most, if not all, resources depend on a File resource, which is the file they were loaded from. If, for example, a model depends on a texture, the model will be reloaded whenever the texture's file changes on disk.

• When a resource cannot be found, or fails to load, a default resource is silently substituted. This allows me to use resources that I haven't yet created, without crashing the game. (Planned feature: indicate "essential" resources such as GPGPU shaders, without which the game cannot properly run at all.)

• Reference counting, and unloading of unused resources, can be added easily. Since my game is pretty small, I haven't had a need for this yet.

I think that this feature list shows that, yes, resource managers can be good!

Answer 3

One of the reasons for having a resource manager is the sharing of resources. For example, when you call resourceManager.Get("sprite.png"), if "sprite.png" is already loaded, the resource manager can simply return a pointer to the already loaded sprite resource rather than creating a new image and reloading it from disk.

A resource manager can also cache resources, so that although the last reference to a resource has been dropped, the resource manager can choose to keep it in memory in case it gets loaded again in the near future. The resource manager would be programmed to automatically handle all memory management with your resources.

Finally, I think a very useful feature is the in-game reloading of resources. Since the resource manager holds handles to all the games resources, you can build in a function which causes all the resources to be reloaded from disk and updating the game in real-time, which is extremely useful for artists/designers who work with your game.

Answer 4

Another benefit is, besides caching and reference counting is that it can handle dependencies (model a needs texture b? I'll get it for ya!) and load order issues (model a needs to know what shader b requires? Let me load shader b before loading the model!)