You could always make your own format, the header would be an index (which associates file 'paths' with file offsets). Each file could be individually compressed, maybe even based on its data type, as audio and images are more efficiently compressed using methods suited to each. Perhaps even a layer of encryption, on the index header, and each asset itself, using your basic XOR against some generated value (from the asset's offset, name, etc)..

It's not difficult to write up a quick utility that will search out all the files in a folder, and its subfolders, and add them to such an asset package.

The *last* thing you want to do is extract an asset back to the disk, just to load it from there. You need to re-write your code so that it directly loads the asset from the packaged file. Writing it out to disk to load it is just silly.

You are about to waste your time. Once the game is in the hands of the user, you can encrypt, obfuscate and do anything else you want and it still takes about 10 minutes for anyone to browse textures, meshes etc. Between DX intercept programs or format browsers such as http://multiex.xentax.com/, your users can get anything they want quickly. Especially if you tried to encrypt the data, you have to provide the key so it doesn't take long for someone to dig that out and open the assets directly even if they don't want to use a DX intercept program.

You can of course do as you desire, but there is really little reason to put any effort into this just for obfuscation reasons.

I can understand 'wanting' to secure some data but really, once it is on the players machine, there is nothing you can do they likely can't hack in less time than it takes you to implement it. A highscore table is just as invalid if they hack collisions/lives/etc as it is if they simply modify it directly. So, why waste the time? The only way to secure data is simply not give it to the user and store it on a server, of course garbage data in from hacked clients is still possible and invalidates the server data also, yer pretty much screwed either way.. :)

Personally I store my assets as resources. (the Microsoft specific standard that stores icons, menus, some strings, bitmaps etc or custom data if you want)

I assume with resource editors it's still as simple to extract non-encrypted files of course but I can ship a stand-alone exe that self-contains everything.

If this solution interests you, look into the following functions on MSN: FindResource(), LoadResource(), LockResource()

The custom type is RT_RCDATA and is "defined" as 10. You would need to pass that value to the FindResource() function.

As an aside, I disagree that encrypting/obfuscating a program is useless because somebody in the world (a clever hacker) will undo that anyway. You can still buy some time and avoid every script-kiddie and his grandma to already steal your assets. If it were really useless then AAA titles wouldn't go to so much trouble doing it. Whenever you ask how to do this here, you are either suspected of wanting to bypass such a scheme yourself to steal a game (which sort of proves that such a system IS useful or why would they be so afraid that you bypass it) or maybe there is some elitism in which newbies aren't encouraged to be able to code to the same protected standards.

There are some older threads with a similar subject here on GDev, and some of the posts in them make a great point on the subject - in fact, it would be a shame not to reference them:

http://www.gamedev.net/topic/506247-why-do-game-companies-use-custom-texture-formats-instead-of-the-dds-format/

http://www.gamedev.net/topic/605910-encrypting-images-png-with-directx/
http://www.gamedev.net/topic/577588-what-are-some-simple-ways-to-protect-my-games-assets-sprites-sound-music-etc/
http://www.gamedev.net/topic/316093-protecting-game-assets/
http://www.gamedev.net/topic/627723-packing-the-game-resources/
http://www.gamedev.net/topic/547471-protecting-shader-code/
http://www.gamedev.net/topic/555394-binary-file-writing-making-it-unreadable-c/

To my view, the point most people make against the encryption-for-protection idea is that the best kind of protection for your assets is the legal one. Make a good copyright claim, a good EULA document.
But they do make a point for managing your game asset file formats in a sense that you should write it in a game-engine specific, binary manner so as to load it as fast as possible (meaning just dumping the data to memory and setting up your pointers, without having to parse data extensively). This kind of binary file formatting provides a "side-effect", unintentional protection as you wouldn't be dealing the original formats anymore. So as Hannah Montana would say, it's the best of both worlds.

As an aside, I disagree that encrypting/obfuscating a program is useless because somebody in the world (a clever hacker) will undo that anyway. You can still buy some time and avoid every script-kiddie and his grandma to already steal your assets. If it were really useless then AAA titles wouldn't go to so much trouble doing it. Whenever you ask how to do this here, you are either suspected of wanting to bypass such a scheme yourself to steal a game (which sort of proves that such a system IS useful or why would they be so afraid that you bypass it) or maybe there is some elitism in which newbies aren't encouraged to be able to code to the same protected standards.

I have never encrypted data in a game client and I've shipped quite a few. Not bothering has nothing to do with elitism, or any particular belief things should be open/free for access, it is simple practical reality, it doesn't work and is a waste of time. Additionally, if grandma wants to make her character pink instead of brown, more power to her as long as she enjoys the game and hopefully paid for it. The only typical encryption in AAA titles, and it's just obfuscation really, is because the formats are written custom with practical reasons in mind such as speed, i.e. pack files are used by many games purely because it is hugely faster to load multiple pieces of data from a single already opened file than it is to load from multiple loose files. Often the data is also compressed, again, this is not usually an attempt to increase obfuscation or implied encryption, it is just a practical reason that at the cost of some CPU it is faster to load and decompress than wait for an HD to read in the entire uncompressed piece of data. Or the data looks like garbage but is really precompiled script VM or other things like that.