Protecting game assets through archiving

Question

I'm writing a game in C++ (with OpenGL) and am getting quite far into development. Currently I'm loading the data directly from different directories.

(E.G. I load textures from a /Data/Textures/...png)

This is fine, but not preferable. Ideally I would like to protect these assets without too much of a performance hit. I looked at other games that I own, both Indie and AAA and found that the majority of them archive the data. However, I am unable to access these archives with programs like Winrar Archiver which implies that they have some level of protection.

I'm not particularly knowledgeable in the field of encryption and data storage, so I may be overlooking something obvious but I would like to know how exactly I could achieve something similar.

(I am aware that competent individuals are able to use the GPU to gain access to the data but that's not preventable)

Answer 1

As others have said, there is no real protection for your assets. That doesn't mean you have to push them out there totally unprotected, though.

Having your own internal format for your assets is pretty useful or even necessary in the long run anyway. If you have your own file format that is not easy to open in content creation tools then it serves just as much for security as any kind of archive system.

You can do the same as well for image formats. I mean do you really want to store 80 types of files in a shipping game anyway? You can have an internal variable or encoding of some kind if you really want additional protection - or if you want to have the ability to have some files protected and others not.

I would make it so that you do not do this by default though, it is a serious drag for people working on your engine. Just allow for a deploy batch job that protects all the files for you before shipping.

A package is nice too so people can't even see file names, but it is pretty pathetic as a security measure, it just means you have put every file together and hidden the directory structure, really. So you make it harder on modders but don't really provide any security.

As for the issue of protection itself, I don't think it matters a lick if you are just putting a game out there. Why make it hard for people to mod whatever dumb stuff they want in there? Sometimes the mods can really help a game look better for that matter.

Yet you are probably going to need it eventually if you expect to have third party customers using things. Especially if you want people making various art packs for your engine. There's nothing that can really stop a determined thief but they won't make a pack for your engine at all unless you have some sort of provision to protect their work.

Answer 2

Sometimes resources seem inaccessible because the devs used customized or proprietary formats, I.E. appending sound effects to the end of sprite image file.

Keep in mind while it's possible to obfuscate the resources, but you can't fully protect them. Even if encrypted, your game will need to decrypt them before use & will need the key. If the key is in the game, the user can extract it. If the game gets the key from a server, the user can intercept it.

Answer 3

I'm not particularly knowledgeable in the field of encryption and data storage, >so I may be overlooking something obvious but I would like to know how exactly I >could achieve something similar.

I don't know a ton of stuff about encryption or advanced data storage either. :)

However, one relatively simple way to protect the program assets would be to embed the data directly into the program. Instead of having an external "image.png", you could instead put the data representing that image into an array somewhere in your program. (A quick google search yields this). I'd suggest writing a quick program to convert from image to array. Anyways, once you have the image data stored in an array, you can simply load image data from there rather than the external image, eliminating the need to include the .png files with your projects.

Audio files could potentially be stored as binary data, but I'm not sure how that would work. Sorry. :(

Keep in mind that any changes to the image would require recompiling the file, and that if you have multiple large images the final program may be larger than it would be otherwise -- after all, you're storing the entire image inside the executable.

---

Apparently, if you're working on Windows then you can simply embed the assets as resource files inside the program, though I can't vouch for the ease or effectiveness of such a procedure: Stack Overflow post; MSDN link.