Old SCUMM File Format

(Indiana Jones and the Last Crusade, CDROM version of Loom, Secret of Monkey Island)

With Indy3, the file format used for SCUMM started to be standardized. Rather than just having all the data stored in a huge mess, LucasFilm Games started to use a format reminiscent of the IFF format (they would get even closer to IFF with MI2 and later games - the "New SCUMM File Format").

The file format is built up of blocks, each having a name and a size. The size is stored first, as a dword (four bytes), little endian. After that follows the block name, as two characters, for example "LE". After these 6 bytes comes the block data.

The size mentioned before includes the 6 bytes making up the size and the name as well as the size of the data following these 6 bytes. Example:

08 00 00 00 "B" "X" 00 01

... would be an entire block, the size is 8 - the four bytes, the two characters, and the two bytes of data. The new format was hierarchal, blocks could be contained within other blocks to give the file more structure. Storing a block within another simply meant putting the block within the other's data area - i.e. right after the first 6 bytes of the parent block - or in some rare instances, a having some data and then a subblock. As long as the block is stored within the size of the parent block, we call it a subblock. Normally, additional subblocks will be stored right after the end of the previous block. The scheme of a standard block thus looks like this:

dwSize	dword	Block size (LE).
sName	2*char	Block name.
data	(dwSize-6)*byte	Block data.

In the early games, the first block is an RO (room) block, containing other blocks describing the room, such as BX (boxes), OI (object images) etc. After the RO block, within the same file, is the global scripts for the room (SC), the sound (SO) etc. With MI1 the programmers started to bundle the files for each room into a big disc-sized file. The basics of the format is still the same, but rather than having a structure like this:

RO
 HD
 CC
 SP
 BX
 ...
SC
SC
SO

(where HD, CC, SP etc. are subblocks of the RO block)... it would be like this:

LE
 FO
 LF
  RO
   HD
   CC
   ...
  SC
  SC
  SO
 LF
  RO
   HD
   ...
etc.

To give an example, the start of a file structured like this would look something like this (taken from the disk01.lec file of the PC version of MI1):

4A C6 10 00	Size of LE block = 0x10C64A.
"LE"	Name of block.
66 00 00 00	Size of FO block = 0x66 (subblock of LE)
"FO"	Name of block.
13 0A 6C 00 00 00 1C ...	FO block data (0x60 bytes).
4F DE 01 00	Size of LF block = 0x01DE4F - note that we haven't yet reached the end of the LE block, so this block is also a subblock of LE.
"LF"	Name of block.
0A 00	LF block data. We have now read 8 bytes of the LF block, but its size is 0x01DE4F, so, although the next block doesn't come right after the 6 initial bytes of this block, it still must be a subblock of LF.
2C  DA  00  00	Size of RO block = 0x00DA2C.
"RO"	Name of block.
etc.