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.

Not exactly. I think this is a valid question.
–
RicketAug 4 '10 at 19:28

Not quite, but similar areas, and similar pros/cons. But there are things you'd do with the manager that you wouldn't do with a manifest. Manifests are dumb things that simply gather together disparate resources into a single index. A resource manager can have much more responsibility, and better interfacing with the game engine.
–
MrCrankyAug 4 '10 at 19:28

I don't think I'm asking the same thing. That seems to be asking whether you should have some kind of file-path shortener, whereas I'm asking about sort of a resource loader/cache type thing. However, I think that didn't appear in seach as I used resource rather than asset.
–
The Communist DuckAug 4 '10 at 19:36

2

@Bryan, I disagree, "are asset managers a good idea" is a different question than "how do you implement asset managers". Granted, some people were trying to answer the first question for the second question, which would cause a lot of answer overlap.
–
Tetrad♦Aug 5 '10 at 4:07

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!

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!)

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.