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:

• Production Mode - all assets are local and stripped of all meta data
• Development Mode - assests are stored in a database (e.g. MySQL, etc) with additional meta data. The database would be a two tier system with a local database caching a shared database. Content creators would be able to edit and update the shared database and updates automatically propegated to developer / QA systems. It should also be possible to create placeholder content. Since everything is in a database, queries can be made on the database and reports generated to analyse the state of the production.

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.

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:

• Production Mode - all assets are local and stripped of all meta data
• Development Mode - assests are stored in a database (e.g. MySQL, etc) with additional meta data. The database would be a two tier system with a local database caching a shared database. Content creators would be able to edit and update the shared database and updates automatically propegated to developer / QA systems. It should also be possible to create placeholder content. Since everything is in a database, queries can be made on the database and reports generated to analyse the state of the production.

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