hiding game data

[ehbgamer]

Hello,
I'm wondering how you usually hide your game data. Myself I used to change file extensions! so that people will not easily double click my files then open it and see (or use :mad: ) all gfx and sfk/music.
Surely there are better methods, I know that some games usually pack all its data in one big file containing all files in one file, actually this is interesting but I'm wondering if there any library to facilitate that, or should I build every thing from scratch?
Some people may build thier file format, but I do not prefer this as it is not possible to make better compression for example (specially for music than mp3 or ogg).
I'm wondering how you guys handle this issue.
Regards,

[Rainer Deyke]

I don't believe in hiding data from the user. I combine all of my data files in one big (compressed) file, but that's for efficiency, not data hiding. I use a custom file format because this was less effort than implementing a standard format, and because I couldn't find any portable free zip file libraries that don't come with licensing issues.

[James C. Smith]

I combine all of my data files in one big uncompressed file for efficiency.

[Matthew]

MoleBox is a product that may suit your needs. I don't use it, personally, and don't really see a need to use it...but just FYI:

http://www.molebox.com/

[oNyx]

>I combine all of my data files in one big uncompressed file for efficiency.

I also do that. The reason is quite simple: you get a good chance to have all data next to each other. Physically - on the hdd. So there aren't big jumps anymore. The head's travel distance is very short from file to file, that speed things up a bit.

Some things were already covered in the graphic filesize (http://forums.indiegamer.com/showthread.php?t=812) thread.

Well, and protecting your media isn't worth it. Even the big players doesn't do that. Id software for example. Their pk3/pk4 files are just zips with another extension. If someone wants to rip their stuff they will be able to do that, but then again why should they? And what for?

If you want placeholder stuff you can get plenty from google, you can get complete sprite sheets from most popular console games. You can get free sprites. You can get free sounds. If they change stuff in your game... well, that's great. Most people who are nowadays into gamedev started with doing such stuff and if they break the game... they'll know it was their fault.

Your media is already protected - by copyright law. If someone steals your stuff and makes s-loads of money. Great. Sue em to hell and the money will be your's. For those reasons no one cares about that.

However, packing by itself is a nice thing. An uncompressed archive can be compressed really well - much better than a bunch of single files. So you might want to take a look at that.

zlib's license looks ok-ish, but I guess there are also other usable libs.
http://www.gzip.org/zlib/

[Jim Buck]

copy /b file1+file2+file3+...+filen filefinal

:)

[svero]

For years we didn't hide the data in any way. Fairly recently, last 2-3 games we changed our install setup to wrap all the files into one big data file. Internally in our code it's something like...

mysprite.init("img/sprites/redball.png");

...and the init code boils down to...

if(big data file exists)
{
traverse path in data file and get file data from there
}
else
{
just load file normally
}

[kerchen]

I pack all of my data into a few big (custom-format) files (one for music/sfx, one for text strings, one for UI bitmaps, etc). My primary reason for doing this is so that I don't waste the user's hard disk space by dropping a bunch of tiny files on their platters. 1000 1Kb files will use 4MB of hdd space on a system with a 4Kb cluster size (which is fairly common, I believe). A secondary concern was protecting my game's assets, but that's mainly because some of my game assets were contracted works which stipulated that I take some precautions against casual content ripping.

[alessia-lee]

You all have already mentioned, that there are other reasons to pack the game, besides hiding data files from users, like increasing file reading speed and decreasing overall game size, preventing accidental file deletion or corruption.
Some people also use Molebox as an addition to, or instead of protection system, and some use it to make addons distribution easier.

[NuriumGames]

I'm using molebox ( http://www.molebox.com/ ) works fine for me.

[Ryan Clark]

What language and library are you using? C++/DirectX? SDL?

If you're using SDL, here are a couple of tutorials that might help:

Creating Custom Resource Files (http://gpwiki.org/index.php/C:Custom_Resource_Files)
Displaying a Bitmap from a Custom Resource File using SDL_RWops (http://gpwiki.org/index.php/C:Displaying_a_Bitmap_from_a_Custom_Resource_File_ using_SDL_RWops)

For DirectX... I only know of a Visual Basic tutorial, alas:

Loading Surfaces from Custom Resource Files (http://gpwiki.org/index.php/VB:DX7_Loading_Surfaces_from_Custom_Resource_Files )

I hope this helps!

[Aggrav8d]

Packing all your data into one big file...
...looks "clean"
...makes it easier to do a CRC check.
...is a good idea because the data can be sorted according to the order it is read in which, with buffering, almost eliminates seek times.
...for shared resources and one for "mission packs" is an alternative that could be quite attractive. It makes counting the number of mission packs at load time very easy. It also means the community can just download a single file and pop it into the "missions" folder and go.

I was putting everything into a big RAR file (with extention changed to PAK) but found that it make the windows installer *bigger*. I have also tried using Jari Komppa's CFL library. It's nice but I find the maintenance when I change content to be a pain in the ass compared to RAR files. My latest feeling on the subject is two or three big stream files managed by my FileEngine and FileBase wrappers. Load times are rediculously fast and it only requires two or three extra lines in code once the wrapper is working. (Open stream now, Close stream now, and Exclude this file from being written to stream.)

[oNyx]

Loading a Texture From a Zip File in DirectX 9 (http://www.gamedev.net/reference/articles/article1992.asp)
some compression stuff (http://www.gamedev.net/reference/list.asp?categoryid=25)
Stack 'em, Pack 'em, and Rack 'em. (http://www.gamedev.net/reference/articles/article825.asp) (Covers the creation of a file system)

There are tons of articles about that out there.

>I was putting everything into a big RAR file (with extention changed to PAK)
>but found that it make the windows installer *bigger*.

That isn't surprising actually. If you have two compression schemes where A is the cheap one and B is superior. You'll end up with a bigger file if you compress the data first with A and wrap it then up with B.

You get by far the best compression if you first pack your data uncompressed and then compress it as strong as possible (eg lzma). You can for example do the same even with zip. As odd as it might sound... but zip (store) then zip(max) results in a smaller filesize than just using max zip compression. You won't see that kind of phenomena with newer formats like 7z.

So, you can continue using rar, but you shouldn't use compression for that archive. You'll see that the installer gets smaller that way. (It's because compressed data is almost impossible to compress - even for superior compression schemes)

As a side effect loading times will be shorter, but used disk space will also increase.

[ibsta]

What does it exactly mean to package all of your data (binary and text) into a single file. How would you access the individual data? Would you pack them only for the purposes of the installation and then extract them to the users machine? Or, would the data be directly read from the archived file using a file scheme?

[Ryan Clark]

You pack it all into a single file, and leave it there. You can access individual chunks of the stored data by using some sort of "table of contents" at the beginning or end of the resource file, which tells you where to find the various files stored within. You then read out the information you're interetested in.

See the links I posted above for an actual implementation!