management tool (Asset Studio) but also ask for similar stories.
When I use the word 'asset' I mean images/textures, image/texture sections, fonts, animations, sounds, meshes, GUI dialogs, text tables, value tables, key/value tables, 2d layered free section and tile maps with objects.
In the days of yore (think DOS with Turbo Pascal 3) I added assets in code directly. There were no asset classes, or a manager. Only bits, and even the zeroes were... ahem.
In later days assets were handled classes, external files and complicated to handle. There are images, sounds, text tables, GUI dialogs. You name it. When tackling bigger games I stumbled again and again over the problem, that I wanted to reference other asset types, but couldn't, as they were stored in different files. There were different editor executables which didn't know anything about the other types.
The final solution was to add a asset file, that kept crucial information in one place. This was stored in XML. There were still external files for more complex assets (you really don't want to put a texture in an XML file). And to manage all assets I wrote an asset manager, namely Asset Studio.
This tools incorporates the whole asset type range and even has editors for the simpler assets.
Assets are referenced by name, so both asset type and name combined must be unique.
I used Asset Studio extensively for my Week of Awesome II entry "Building Blocks" (Post Mortem here: https://www.gamedev.net/blog/949/entry-2260318-the-week-of-awesome-ii-post-mortem/)
I'm pretty happy to finally have inter asset type references. I can see the chosen font and images in GUI dialogs, have text tables as source for GUI components, key/value tables as object templates for 2d maps, etc.
The underlying code is not really that clean IMHO but clean enough for now (TM). I do have a base class that stores the type specific asset info. Since my game framework is plugin based, and some assets are plugin specific, there is no real single location to load assets. Basic assets (text tables, GUI dialogs) are loaded by the framework itself, other assets (textures) are loaded by the relevant plugin on "loadup".
Practical problems I'm aware of are:
* Asset lookup is string based, not the fastest
* Theoretically plugins can be switched at runtime, this could lead to errornous asset caching (if I wanted to avoid string lookup). Probably the reason why I do not switch plugins at runtime
* Normal Asset types appear at level 2 of the XML hierarchy. Only exception are GUI dialogs, they allow nesting.
Wishlist:
* Prepare binary asset package file
So, how did you approach assets?
My current, very much WIP asset management consists of a single config file -- config.json -- that coincidentally is, no doubt, moving in the same direction as yours. I've been slowly refactoring everything out of the original config.hpp ... Your journal post makes me feel much better about my own design! :-) I do probably need to start considering branching out a separate assets.json file, to keep the game config separate ...
Internally speaking, I do have support for handling multiple object nodes, so I could very well implement something much like yours, but what has me uncertain at this point is how I ought to best handle the issue of multiple scales of assets (i.e.: 64x64, 128x128 sprite tiles, which are loaded depending on game resolution, device or what not).
Have you given this particular side issue much thought? I figure that perhaps you would simply devise a child node underneath the parent node for this kind of configuration?
My first attempt at solving the problem was rather messy for my likes, as it involved loading a separate config file depending on the resolutions. I figure that it is probably best for me to keep everything grouped together, as it stands now ... but I'm very much learning as I go, so :-)
P.S. For the side issue of handling file paths with assets, I've recently started using data-driven files for engine examples/tests that specify search prefix directories to combine with the 'path' string to use in its determination of where the assets are located. I haven't yet combined this method with the game (config.json & friends), but do plan on experimenting with a combination approach of some sort in the future... it has worked great on the engine side of things, on both Windows & OS X. Underlying rationale for this sort of thing is better explained here.