What is the best approach to designing an AssestManager that will hold references to graphics, sounds, etc. of a game?
Should these assets be stored in a key/value Map pair? I.e. I ask for "background" asset and the Map returns the associated bitmap? Is there an even better way?
Specifically I'm writing an Android/Java game, but answers can be generic.
It depends on the scope of your game. An asset manager is absolutely essential for larger titles, less so for smaller games.
For larger titles you have to manage problems such as the following:
For smaller titles these things are less of an issue, frameworks like XNA have asset managers within them - there is very little point in re-inventing it.
If you find yourself needing an asset manager, there is no one-size-fits-all solution really, but I've found that a hash map with the key as a hash* of the filename (lowered and separators all 'fixed') works well for the projects I've worked on.
It is usually not advisable to hardcode filenames in your app, it is usually better to have another data format (such as xml) depict filenames to 'IDs'.
(Trying to avoid the "don't use an asset manager"-discussion here, since I consider it offtopic.)
A key/value map is a very usable approach.
We have one ResourceManager implementation where Factories for different Resource types can register.
The "getResource" method uses templates to find the correct Factory for the wanted resourcetype and returns a specific ResourceHandle (again using the template to return a SpecificResourceHandle).
The resources are refcounted by the ResourceManager (inside the ResourceHandle) and released when they are not needed anymore.
The first addon we wrote was the "reload(XYZ)" method, which allows us to change resources from outside the running engine without changing any code or reloading the game. (This is essential when artists work on consoles ;) )
Most of the time we have only on instance of the ResourceManager, but sometimes we create a new instance just for a level or a map. This way we can just call "shutdown" on the levelResourceManager and ensure nothing is leaking.
// very abbreviated!
// this code would never survive our coding guidelines ;)
ResourceManager* pRm = new ResourceManager;
pRm->initialize( );
pRm->registerFactory( new TextureFactory );
// [...]
TextureHandle tex = pRm->getResource<Texture>( "test.otx" ); // in real code we use some macro magic here to use CRCs for filenames
tex->storeToHardware( 0 ); // channel 0
pRm->releaseResource( pRm );
// [...]
pRm->shutdown(); // will log any leaked resource
Dedicated Manager classes are almost never the right engineering tool. If you only need the asset once (like a background or map) you should only request it once, and let it die normally when you're done with it. If you need to cache a particular kind of object, you should use a factory that first checks a cache and otherwise loads something, puts it in the cache, and then returns it - and that factory can just be a static function accessing a static variable, not a type of its own.
Steve Yegge (among many, many others) has written a good story about how useless manager classes, by way of the singleton pattern, end up being. http://sites.google.com/site/steveyegge2/singleton-considered-stupid
What I like to do for assets is to set up a lump manager. Inspired by the Doom engine, lumps are pieces of data that contain assets, stored in a lump file that declares lumps' names, lengths, type (bitmap, sound, shader, etc.), and content type (file, another lump, inside the lump file itself). On startup, these lumps are entered into a binary tree, but not loaded yet. Each map (which is also a lump) has a list of dependencies, which are simply the names of lumps that the map needs to work. These lumps, unless they've already been loaded, are loaded at the time the map is loaded. Additionally, the map's adjoining maps' lumps are loaded, just not at the same time, but when the engine is idling for some reason. This can make the maps seamless, and there is no loading screen.
My method is perfect for open-world maps, but a level-based game won't benefit from the seamlessness this method gets you. Hope this helps!
I've always thought that a good asset manager should have several modes of operation. These modes would most likely be separate source modules adhering to a common interface. The two basic modes of operation would be:
You'd need a tool that can grab all the assests from the shared database and create the production dataset.
In my years as a developer, I've never seen anything like this, although I've only worked for a handful of companies so my view is not really representative.
Update
OK, some negative votes. I'll expand on this design.
Firstly, you don't really need factory classes because if you've got:
TextureHandle tex = pRm->getResource<Texture>( "test.otx" );
you know the type, so just do:
TextureHandle tex = new TextureHandle ("test.otx");
but then, what I was trying to say above is that you wouldn't be using explicit filenames anyway, the texture to load would be specified by the model the texture is used on, so you don't actually need a human readable name, it could be a 32 bit integer value, which is much easier for the CPU to handle. So, in the constructor for TextureHandle you'd have:
if (texture already loaded)
update texture reference count
else
asset_stream = new AssetStream (resource_id)
asset_stream->ReadBytes
create texture
set texture ref count to 1
AssetStream uses the resource_id parameter to find the location of the data. The way it did this would be dependant on the environment you're running in:
In Development: the stream looks up the ID in a database (using SQL for example) to get a filename and then opens the file, the file could be cached locally, or pulled from a server if the local file doesn't exist or is out of date.
In Release: the stream looks up the ID in a key/value table to get an offset/size into a large, packed file (like Doom's WAD file).
