Managing assets

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

Recommended Posts

Alright, what I have right now is a CTextureManager, which handles loading textures, keeping them in a texture list, etc... it works great. I also have a CModel class, and I am going to have to have a manager for that as well, to make sure I don't load the same model 40 times. Now, when I get to sound, I'm going to have to do the same thing. My question is, would it be more beneficial do have seperate managers for each one? Or should they all be incorporated into one CAssetManager class? I can see benefits to both methods of doing it. CAssetManager would be simple to use on the outside, but really messy on the inside. If I did them seperately, I could mess with them seperately, in case they need to be managed differently, and might make debugging a bit easier. Any input or advice? I'm not an uberprogrammer, so lets try to be a bit basic and not through out polymorphism options and things like that, if possible, heh. I'm not sucky, but not rad either. Any help is greatly appreciated.

Share on other sites
I'd either make the manager templated, or I'd explicitly make each one since there's not so many. Since you say you're not so experienced, and loading resources is pretty vital, I'd suggest just taking the time to impliment each one.

Share on other sites
I would create a templated asset manager. std::map or std::hash_map makes managing this pretty easy for the simple cases. You probably also want a shared_ptr or ref-counted pointer class to manage lifetime of the assets.

Beware case sensitive string compares on non-case-sensitive file systems, though -- you might want to lowercase all names/paths that come into the asset manager (and do the same to your asset file names).

Share on other sites
But what is the need of making a templated base manager or whatever? I'm not writing Half-Life 3. I'm making a small game, i'm the only programmer. Spending all my time writing complex managers will do me no good, and will keep me from making the game.

I'm not trying to write something that will be 100% versatile no matter where I use it. My scope for this game is minimal. Again, it's not half-life 3.

So, that being said, any other suggestions? Remember, im trying to be simple with this, templated base managers seem to be overkill for this project.

Share on other sites
Consider the scope of your project and code accordingly. You can do it any way you like, and you seem to have a good grip on the benefits and shortcomings of either method. If it's a small game there's no harm in keeping things seperate and somewhat hardcoded. By then end of the project you'll have encountered the problems you'll want to solve next time around.

Share on other sites
You know what, i encountered this exact same problem and put an end to it a few days ago.

In the past i had a MeshManager, TextureManager. At that time i realised that i was rewriting the asset management part for these 2 managers. But since i was lazy and short of time, i said it's only 2 Managers, it won't be worth rewriting. Then came a MaterialManager which loads Materials. In the future when i implement shaders, there will be a ShaderManager, then a SoundManager and a Manager for any resource which can be used by more than 1 entity.

Since i have a couple of weeks of leave, i finally did something about it. It took barely and hour to get everything done.

First, I made, Textures/Meshes/Material classes inherit from a Resource class.

class Resource{Resource(){ResourceManager::getResourceManager().addResource(this);};String filename;int ref;}//same for meshes/materials.class Texture: public Resource{....};/*This only took 5 mins.Now the Manager part. I removed all the individual managers from the project. and did this. Tada, any class which inherits from Resource will be automatically added and managed by ResourceManager upon creation.*/class ResourceManager{void addResource(Resource* r);std::list<Resource*> resources;}

Share on other sites
Thanks gamer, that helped. That's about the kind of system I need. I think I will implement something like that, thanks a bunch.

Share on other sites
One more point i forgot. I moved all the resource-file loading code from individual managers into the class itself as a static function.

class Texture : public Resource
{
}

In this way the file loading routines are abstracted away from the ResourceManager. So it is possible for anyone to make their own Resource type without having access to the code of Resource/ResourceManager.

Also, to check if a resource is already loaded, you could add a function to do this in the ResourceManager.

class ResourceManager
{
}

{
if(t)
{
return t;
}
else
{
}
}

Share on other sites
Why static though?

Share on other sites
Well that's how i prefer to do it. Because i find file loading a utility function. Main reason being that previously the TextureManager used to do the same thing, it returned a Texture* object. In this way i could just copy the entire function and not have to make changes to anything other than the function definition.

Static

as opposed to
Non-Static
Texture* t = new Texture();

It makes little difference if it is static or not.

• 10
• 17
• 9
• 13
• 41