Packaging Game Files


Miner49er

Active Member
Joined
Mar 1, 2004
Messages
655
Age
49
Website
www.lessermatters.co.uk
Hi there folks,

I'm working on a game for use on the pandora (and any other computer). I have several things left to do on it and tidying up all the last bits is a bit ad-hock at the moment but right now as my game has lot's of other files it needs I am looking for a way of packaging them up so as it's all a bit neater.

Ideally, I would like the game to be a single file but I will be happy with a single 'data' file.

Now, my first thoughts were to just 'zip' all the files up and rename the file gameData.dat - is this the recommended way of doing it? If so, what libraries would I use to get at the files?

Any ideas would be great. I know I should work more on the game mechanics before doing this bit but like I said, it's all ad-hock hacking right now!

I'm coding in C++ under linux atm and I want this to be cross-platform, so I'm not interested in Exec()'ing tar -xjf etc.

cheers,

m
 
You could roll your own DAT/WAD tool, that just takes a bunch of files, concatenates them together, and produces a table of each offset/file length. Or as you say, you could just zip them up, zlib has an example for working with zip files, that might be of help there. Personally I've opted for the custom rolled tool, as it seemed pretty quick to do, and works for all platforms/projects in future.

Steve
 
Hmmm, I like the sound of the custom tool - though, I expect adding compression to that tool could be a pain.
Maybe the zimplest option is to zip 'em up.

Thanks for your reply :)
 
zlib is pretty universal since you'll need to recompile for each arch anyway. A simple wrapper and your program doesn't know (or care) whether the files are being read directly from disk (eg. for development) or from a zip file (for public release). Heck, I've even seen zlib code that checks for the presence of a file locally, and if not found, then attempts to find it inside a named archive. That way you can override files by simply dropping them in the directory of the executable, rather than having to to give out entire new archives when people are beta testing for you.

Why roll your own when everything has already been done for you?
 
Squidge said:
zlib is pretty universal since you'll need to recompile for each arch anyway. A simple wrapper and your program doesn't know (or care) whether the files are being read directly from disk (eg. for development) or from a zip file (for public release). Heck, I've even seen zlib code that checks for the presence of a file locally, and if not found, then attempts to find it inside a named archive. That way you can override files by simply dropping them in the directory of the executable, rather than having to to give out entire new archives when people are beta testing for you.

This sounds great, I will use zlib!

Squidge said:
Why roll your own when everything has already been done for you?

For the fun of it? Seriously, if only you knew what I was coding then that statement would appear quite ironic!
 
Last edited by a moderator:
Squidge said:
Why roll your own when everything has already been done for you?

Well there were a few custom things I wanted, so it made sense to roll my own - for instance, some filetypes I want compressed, others I don't (part of the reason being compressed files don't really allow you to seek, which some systems require). It would be possible to write a script that walks through a directory, then calls some freeware zip making program, specifying the filename and if it should be compressed or not, etc. but I decided by time I had gone to all that effort (and found a scripting language that all members of the project have installed etc.) it'd be just as easy to write a custom system! Plus it allows for additional optimisations, such as not storing filenames, and instead just storing hashes, in a sorted list, this saves memory and means locating a file (or checking if it exists) can be done very quickly (not sure if the zlib example does anything simliar). And so on - so there are good reasons I can assure you! :)

Steve
 
Last edited by a moderator:
Squidge said:
Heck, I've even seen zlib code that checks for the presence of a file locally, and if not found, then attempts to find it inside a named archive. That way you can override files by simply dropping them in the directory of the executable, rather than having to to give out entire new archives when people are beta testing for you.
A few commercial games do it like this. IIRC, the Neverwinter Nights games are among them. I think it's a great way of managing data files as it not only makes beta testing more comfortable but also allows users to more easily mod the game – and even if you didn't plan on modding, the community might just decide that it wants to so making it easier for them is the awesome thing to do.
 
Last edited by a moderator:
Back
Top