Deadlock's file formats

[kelvSYC]

I'm wondering if anyone has attempted to reverse-engineer the file formats to Deadlock or Deadlock II, since I've started an effort to do so (primarily because I've wanted a more protracted Shrine Wars game).

[SonOfDon]

I'm wondering if anyone has attempted to reverse-engineer the file formats to Deadlock or Deadlock II, since I've started an effort to do so (primarily because I've wanted a more protracted Shrine Wars game).

Welcome to the forum.

The Ubergeneral will be able to give you some ideas.

[Ubergeneral Grunt]

Welcome to the forum, kelvSYC.

Game Extractor is able to extract data from some of Deadlock II's data files. I have been able to extract the sound and music, plus dialog strings and the cinematics (which appear to be Smacker video files, but I can't get them to play). The sprite file seems to be the same as Deadlock I, which has a relatively unknown format.

Paul Kwinn (MoeMoose), has kindly given us some information about how Deadlock's sprite file is compressed:

OK, I can tell you about the compression format, but not sure about spritelg.dat . I think it’s full of sprite pixel data in this format, but I think there was an include file with the offsets for the beginning of each graphic in there. So you’d need the source code (or some extensive guessing) to get the offsets right.

The format (Russell said he thinks it was named PKCompress) was byte-oriented. The first two bits of the initial byte described the type of encoding, and the next 6 were a count (0-63) [possibly, I interpreted those as 1-64, since a count of 0 wasn’t useful].

2-bit code value:
--------------------
0 – Straight copy of the next <count> bytes from input to output.
1 – RLE: the next <count> bytes of output should all be filled with the next (single) byte of input.
2 – copy from earlier in the stream, short offset: the byte following the control byte indicates an offset to a position earlier in the output stream. The next <count> bytes of output should be copied from that position to the output stream.
3 – copy from earlier in the stream, long offset: same as 2, above, except that the offset is the next TWO bytes after the control byte, rather than just one. This allowed an offset of up to 64K.

Deadlock I's video files are Smacker video files, you can get a player from here. If you are using Mac OS X (like me) or Linux, MPlayer may be the best option.

If you have any more questions, feel free to ask me, i'll do my best to answer them.

[kelvSYC]

How about the save game (or map, etc.) file format?

[Ubergeneral Grunt]

I far as I know, no one has reverse engineered the saved game and map files. The save file format in Deadlock (both Mac and Windows, all versions) and Deadlock II, look very similar (believe it or not, Deadlock II's source code was built on top of Deadlock I's). I have successfully changed some territory names in a Deadlock 1 save file, but only with strings that are the same length. That is as far as I have gotten with the save files.

[kelvSYC]

Okay, allow me to get a first crack at this.

It appears that Deadlock only saves the state of the game up to the last completed turn, and then has a list of actions that is to be performed (ending your turn is such an action). That's why you can save at the start of a turn, and reload it as many times as you want and hope that this time the battles turn out in your favor.

Anyways, a Deadlock II save, from what I see, has the following:

Most of the data is gleamed from start-of-game saves, so it's quite incomplete in a lot of areas.

Header Data

Code: Select all

0x00-0x57 string Identifier
0x58-0x9B Currently Unknown
0x9C-0x9F uint32_t Turn Count
0xA0-0xA7 Currently Unknown
0xA8-0xAB uint32_t Number of Players
0xAC-0xAF uint32_t City Centers Needed (Manifest Destiny)
0xB0-0xB3 uint32_t Shrines Needed (Shrine Wars)
0xB4-0xB7 uint32_t Shrine Control Duration (Shrine Wars)
0xB8-0xB9 uint16_t Victory Condition (0 - Manifest Destiny, 1 - Conquest, 2 - Shrine Wars)
0xBA-0xBB uint16_t (Another game setup setting - not sure which)
0xBC-0xBD Currently Unknown
0xBE-0xBF uint16_t Use Random Events
0xC0-0xE1 Currently Unknown
0xE2-0xE5 uint32_t Number of items in the Event Log (the game is dirty in this regard; even a new game might have nonsensical entries!)
0xE6-0xED Currently Unknown
0xEE-0xF1 uint32_t Auto End Turn duration
0xF2-0xF5 Currently Unknown
0xF6-0xF9 uint32_t Auto End Turn - Last Player duration
0xFA uint8_t Racial Abilities (0 - Standard, 1 - Best, 2 - None)
0xFB-0x11B Currently Unknown
0x11C-0x122 uint8_t[7] Player Difficulties (0 - Hog-tied to 4 - Supercharged)
0x123-0x14F Currently Unknown
0x150-0x152 uint16_t Number of Territories (Note that a territory might not be represented on the map at all - the file is quite dirty in this regard)
0x153 uint8_t Map Width
0x154 uint8_t Map Height
0x155 uint8_t Planet Type (0 - Earthlike to 6 - Alien)
0x156-0x15A uint8_t[6] Percentages (of terrain type, in the order Ocean, Plains, Forest, Marsh, Mountain, and Wasteland)
0x15B Currently Unknown

[kelvSYC]

Player Data

Player data immediately follows the header. There are 7 player data blocks (even for a game with fewer players). Unused players are all zeroed out.

Code: Select all

0x00-0x01 Currently Unknown
0x02 uint8_t Race (0 - ChCh't to 6 - Uva Mosk)
0x03-0x05 Currently Unknown
0x06 uint8_t Starting Territory
0x07-0x0B Currently Unknown
0x0C-0x0F uint32_t Credits
0x10-0x4D Currently Unknown
0x4E-0x2A2 Currently Unknown, but it is 6 90-byte structures
0x2A3-0x2C0 string Player Name (treated as a C-style string)
0x2C1-0x2C7 Currently Unknown

After this comes 1764 bytes of data I can't make heads or tails out of. Then what follows is a number of 68-byte structures the purpose of which I am not aware. The number of such structures is also unknown, as I can't find it anywhere in the file (all I do know is that new games start with 7 and that later turns add more to this list)

[kelvSYC]

Event Log Entries

The event log entry is a variable length structure which follows the mysterious 68-byte structures.

Code: Select all

0x00-0x01 - Currently Unknown
0x02 uint8_t Length of Event String
0x03-0x0B - Currently Unknown
0x0C-???? Event String

It appears that the event log entry may also have coded information about the event itself that's repeated in the event string, but I haven't looked into it.

[kelvSYC]

Overworld Map Data

For each overworld map tile, there is a small structure associated with it. The X and Y assume the top-left corner (top corner in isometric view) is the origin.

Code: Select all

0x00 uint8_t Y
0x01 uint8_t X
0x02 uint8_t Territory
0x03-0x09 Currently Unknown

[kelvSYC]

Building Data

Immediately after the overworld map data there is a uint32_t on the number of buildings on the map. Each building then has the following structure:

Code: Select all

0x00-0x03 Currently Unknown
0x04 uint8_t Building Type (1 - Housing to 2F - Underwater Shrine)
0x05-0x07 Currently Unknown
0x08 uint8_t Location
0x09-0x121 Currently Unknown

Among other data I've managed to parse out is racial variation in buildings (such as Housing, City Centre, etc) and possibly number of colonists working it, but I'm not positive as to their location as I haven't played around with it as much.