Jump to content
  • Advertisement
Sign in to follow this  
Itzmattu

Unity Image packaging methods

This topic is 3644 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am beginning to create one of my first PC games, and have been studying the method of deployment for other titles. I noticed one of the winners of the last GameDev contest, Assault on Planet Equidon, had no image files included with it in the install path. This leads me to believe they hard coded all the image data into their game, which is a bit over the top for most projects. Other developers however, like Valve and Blizzard, seem to use proprietary or some form of file packing that only the game knows how to read. (Until of course the community figures it out). This seems a bit more reasonable to avoid easy modding of your games, but still vulnerable. My main question is, what are the most popular forms of packing your data so that they are not openly accessible as .png, .jpg, .bmp files, and et cetera. I don't really have an issue with including them in this fashion, as the project is planned to be open source, and not even copyrighted as it is largely a learning experience. I am interested in the methods used for this however, which is why I've come here to ask. Thank you ahead of time for your input.

Share this post


Link to post
Share on other sites
Advertisement
Just checking in. I hate to bump, but this an extremely interesting topic to me and I would greatly appreciate any reading material or resources on the subject.

Share this post


Link to post
Share on other sites
You don't necessarily have to "hard code" th image data into the game. You can create a resource file which includes whatever files/data you want it to. The resource file then gets built into the .exe. This means that if you want to include an image in your program but not have some .jpg laying around for the user to look at/modify, you can put the .jpg into the resource file, and at compile time the .jpg gets built into the .exe. Then when you need to load/use the .jpg, you just have to write a couple lines of code that asks Windows to get the .jpg resource data from your .exe. It's very easy to do.

However, this method builds the resources into the .exe in a specific layout that is well known, so it is very easy for someone to use a program to extract whatever resources you build into your .exe (Resource Hacker is just one of the many tools that does this). This means that the average user won't be able to see your resource files, but with a little effort they can easily extract and modify them.

PAK files are file archives used by ID Software's Quake game. MPQ files are used by Blizzard. Basically the concept is the same: Create one big file that stores all the data of lots of little files. That one big file can be compressed or encrypted if necessary. Then when you need to load a file, you access the big file and find the data for that little file.

Some companies use their own file formats for the little files. (For example, you can create your own image format or 3D model format). This makes it harder for users to hack your files because they have to first figure out your pack file (your big file), and then they have to figure out each little file.

Share this post


Link to post
Share on other sites
An easy way to do it is the "half bit method".
Here's some example code ( note: not complete of course , but you get an idea ).



somePackPixelsFunction(const char** pixels,FILE** f,const int flags)
{

unsigned char* p = (unsigned char*)(*pixels);
unsigned char r='\0',g='\0',b='\0';
char a='255';
//Step 1 : loop through the pixel buffer

//set r g b
r = *(p++);
b = *(p++);
g = *(p++);

//Full bits
if( flags & FULL_BITS)
{
//write each byte
fwrite(&r, sizeof(unsigned char), sizeof(unsigned char), *f);
fwrite(&g, sizeof(unsigned char), sizeof(unsigned char), *f);
fwrite(&b, sizeof(unsigned char), sizeof(unsigned char), *f);
fwrite(&a, sizeof(char), sizeof(char), *f);
}
else //HALF BITS...
{
unsigned short rgb_packed = (b >> 3)|((g >> 2) << 5)|((r >> 3) << 11);
fwrite(&rgb_packed, sizeof(unsigned short), 1, *f);
}


}



Hope it helps...

Share this post


Link to post
Share on other sites
Quote:
Original post by Itzmattu

I am interested in the methods used for this however, which is why I've come here to ask.


- In-house legal team specialized into intellectual property and copyright laws
- Large budget for said team

Quote:
but still vulnerable


Since all those games use 3D, attacking the files is essentially counter-productive. The by far easiest way is to simply intercept OGL/DX calls.

The primary reasons for these formats lie elsewhere:
- More compact storage, sometimes custom tailored for loading
- Support for features not available in single standard format
- Versioning support (streaming updates)
- Enforcing read-only aspect (if you don't need to modify certain data, it's possible to store it in a different form than conventional file system)
- Various platform tricks that allow loading directly into memory (exotic, mostly unsuitable for modern PC-based systems, but is a perfectly valid method)

Security is typically last priority when it comes to assets. The reason is quite simple - copyright laws have stood the test of time and are enforced with success in most countries independently of software piracy.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!