General Information

The file formats of the citybuilding games are fairly easy to decipher, but increase in size and complexity with each game. The scenario files for Caesar 3 and Pharaoh, for example, don't use any form of data compression or checksums. An overview of compression methods used is in the following table:

Game Scenario files Saved game files
Caesar 3 Uncompressed, fixed size Parts compressed with PKWare DCL
Pharaoh Uncompressed, first parts fixed size;
last part variable (events)
Parts compressed with PKWare DCL
Zeus Parts compressed with PKWare DCL Parts compressed with PKWare DCL
Emperor Completely compressed using ZLIB Completely compressed using ZLIB

Since all games were originally developed for the PC platform, all integer values are stored in little-endian format.

Compression formats

There are two different compression libraries used for the game files. Caesar 3, Pharaoh and Zeus use the PKWare Data Compression Library (DCL), while Emperor dumped the PKWare DCL and moved over to the standard ZLIB library for compression of the files.

PKWare DCL

There is no official specification of this compression algorithm, but Ben Rudiak-Gould posted a complete specification (local copy) in the comp.compression newsgroup.

The citybuilders use this library for compressing certain parts of the game files, while other parts are left uncompressed. A compressed block of data is consistently stored in the following way:

  1. 4-byte integer value (n) specifying the length of the compressed block of data
  2. n bytes of compressed data

ZLIB

Emperor uses ZLIB, with DEFLATE as compression method, for storing its game files. The specifications for these two formats are in RFC 1950 (ZLIB) and RFC 1951 (deflate). The game files are compressed in their entirety, unlike like the earlier citybuilders did with the PKWare DCL. The file to save is chopped up in blocks of 32KiB, compressed and stored. Campaign files consist of multiple "sub-files" within the file: two for the settings and texts, and one for each map used in the campaign. A block of compressed data looks like the following:

  1. 4 bytes of data, a marker to check whether this is a valid compressed block
  2. 4-byte integer (n) specifying the length of the compressed data
  3. 4-byte integer indicating how large the uncompressed data will be, usually 32768 bytes except for the last compressed block of a sub-file
  4. n bytes of ZLIB-compressed data

Last modified on 2008-01-17 19:47:39