Level/Set packaging

Posts: 14
Joined: 2005.12
Post: #1
I'm looking for ideas on the best way to package up levels/card sets/etc. My game is going to have a bunch of different "levels" (I'm using that term loosely. Each level will have a bunch of art work with it, maybe 10-20 images and perhaps some meta data about the level, who created it, what level it's aimed at, etc. I can package a basic set of levels with the application in the main bundle, but in the not to distant future I'd like users to be able to submit them and have them downloaded from the site. Ideally the stuff I bundle with the app would be in the same layout so that the level reading code would work the same, but just take a different path as input.

I've thought about the following:
1. use bundles. I'm using Cocoa, so reading stuff from a bundle would be easy. Iterating over a folder of bundles would probably be pretty easy too. However, this may be difficult for regular users to create unless I package some sort of tool with the game to create them.

2. folders. I could enumerate over all the folders in my app support folder looking for a key file in each to indicate whether it's a level set or not. Would be easier for users to create & modify, but it might make the download a little more troublesome.

3. ?

I'd appreciate any feedback on how people are doing this and what has worked well. I've downloaded a whole bunch of games to look at how other people are doing it.
Quote this message in a reply
Posts: 5,143
Joined: 2002.04
Post: #2
Use a folder, but distribute as a zip file, and have the game know how to unzip the file?
Quote this message in a reply
Posts: 245
Joined: 2005.11
Post: #3
I believe the Quake engine loads data from zip files on the fly, so there are never decompressed folders lying around, and any mod can be supplied as a single file. This kind of approach certainly beats asking users to arrange three or four files in the correct folders (as Neverwinter Nights does). If your data sets are quite large then using low levels of compression (or none at all) will avoid slowing things down too much. Tar files might be better as they use no compression - but the standard approach to reading them can be a bit slow if you need random access. I've never studied the file spec but there may be inherent problems here. On the other hand if you just need to read the whole lot into memory then it should be quite fast as there is no decompression required.
Quote this message in a reply
Posts: 1,403
Joined: 2005.07
Post: #4
Its generally faster to load a much smaller file and decompress it actually.

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Post Reply