):I've been thinking about GamePaks, Nintendo Cartirdges. At least the gameboy ones were named GamePaks. Anyway, everything that was needed for the game was stored (either in compressed or non-compressed form) in the one small plastic cartridge.
When I was developing games for the Gameboy Advance, I had this idea for a resource / package manager program that would give every resource a symbolic name, take care of file conversion, compression, encryption, etc.
So my project GamePak has two modules: The Resource Manager class that is used to extract the data from the GamePak in Irrlicht, and the Package Manager that creates the GamePak.
I see quite a few advantages to this method:
1) Each resource has a symbolic name. Like "Bob hits wall" instead of "Bobwall.mp3". You could make the names as complex or simple as possible. And, if later, you decide to change the sound effect to "Bobwall2.mp3," you make the change of file in the package manager program, but you don't have to change your source code. As far as your game is concerned, the sound effect is still "Bob hits wall".
2) Each resource becomes one type. The engine wouldn't have to have a 3ds loader and a obj loader and am mim loader. The Package program would convert all the models to one type. This would allow you to use a less complex version of the engine. (Regular Irrlicht would retain all the loaders, but there would be a stripped down version?)
3) You could use pristine resources, then dynamically degrade them for use in the GamePak without effecting the original resource. For example, if I had a large PNG that I wanted to use as a texture for a spaceship, I would import the PNG into the Package Manager, then tell the package manager to make it a "Lossy" compressed image with a quality of 20. Then, later, if I decide I want a better quality texture, I could up the quality to 50. Or I can change the texture's dimensions. The point is that I don't actually ever edit the original pristine PNG. I make a copy of the data and fiddle with that. In this case, I have full control of the quality of all the resources. (Anyone who's ever used the Macromedia Flash Library knows what I mean. It's a great resource for quality<--->size optimization!)
4) I hope eventually to have optional encryption of the contents of a GamePak. All GamePaks can be password protected, but as ZIP enthusiasts know, it's easy to corcumvent passwords. However, by encrypting the data, you can protect it. In that case, you would have to write your program to pass a decryption "key" to the GamePak resource manager to deencrypt your game resources.
5) A "raw" resource type would be supported, to allow you to put in any kind of resources that GamePak doesn't know about.
I've got a VERY preliminary version of GamePak in progress at home, but whilst I waas working on it, I had a question and a request for comments/features.
1) To the best of your knowledge, is it better to pack information into attributes of an XML file (eg: <package name="a" encrypt="y" opensource="n" passwordmd5="XXXXXXXXXXX">), or is it better to make separate tags (<package><name>A</name><encrypt>y</encrypt><opensource>n</opensource><password MD5="XXXXXXXXXXXXXXX"/>)