I need help decrypting files!!! Details in comments.

Here's some stuff from a first look (I've never played the game, so I don't have much to correlate this stuff with):
The .AMM file: The file is defined by a a series of tags, some with length-prefiexed bodies (which ones are length-prefixed and which aren't seems to be tag-dependent). The tags can be either 4 or 8 bytes; there doesn't seem to be a specifier other than looking at the first part of the tag. The body of each length-prefixed tag is prefixed by a 4-byte LE unsigned int length. The tags are:
FORM (not length-prefixed): 0x7a350b00 // Format string probably, makes sense that it'd occur first MAP CSUM (length 4): 0x7981d69d // likely crc?
VERS (length 8): 0x06000000 0x16000000 //version information
DESC (length 2): 0x0000 //unknown - it's possible that this is a string, as they seem to be null terminated to 2-byte alignment. A look at other files should be able to confirm or reject this.
AFIL (length 14): playset1.txt //a string valued file reference. Not included in the zip archive. Null terminated twice, probably for 16-bit alignment.
OFIL (length 2): 0x0000 //unknown, but suspected to be another string. Compare with other files.
ASCR (length 2): 0x0000 //unknown, probably string again
PSCR (length 2): 0x0000 //unknown, probably string again MHDR (length 12): 0x00010000 0x00010000 0x01000000 //no clue, possibly related to high dynamic range lighting?
TNAM (length 22): bootcamp_reduced.ATL //a filename, double-null-terminated.
ONAM (length 10): bootcamp //a name for something, double-null-terminated.
TLAY (length 131092): this is a good chunk of the file. There's a lot of repeated data in here; is the game based around multiple rooms? OLAY (length 12836): a brand of skin care products. More seriously, this looks like lot of shorts padded to take up 4 bytes each, making it 3209 entries. Very conveniently, we can determine that they're probably not grouped up further because 3209 is a prime number. Potentially layout vertex data?
OATT (length 184): 0xb8000000 0x08000000 // This tag specifies that it contains 8 tag name-number pairs. The following 8 tags are the contents of this tag's body.

INDX (not length prefixed): 0x01000000 // count of number of tags expected later?
MOVE (not length prefixed): 0x01000000 // count of number of tags expected later?
ELEV (not length prefixed): 0x01000000 // count of number of tags expected later?
OWNR (not length prefixed): 0x01000000 // count of number of tags expected later?
TRIG (not length prefixed): 0x01000000 // count of number of tags expected later?
NUMB (not length prefixed): 0x01000000 // count of number of tags expected later?
GRUP (not length prefixed): 0x01000000 // count of number of tags expected later?
SCRI (not length prefixed?): 0x04000000 // count of number of tags expected later?
This tag has a 116-byte body following this tag list. Purpose unknown MOVE (length 65536): This is the second time we've seen a MOVE tag, but this time it seems to have a length, and a power-of-two length at that. All of the bytes in the body of this tag are either 0x00 or 0x0f.
ELEV (length 65536): Looks like a pattern is emerging. Due to the recurrence of these tags, it looks like the first occurence of these was indeed part of the OATT tag, and it was listing the tags in the body and the number of each that would occur. Still dunno the purpose of this ELEV tag though, the entire block is filled with 0x00.
OWNR (length 65536): See above. Entire block is 0x00.
NORM (length 65536): See above. Entire block is 0x00.
TRIG (length 65536): See above. Entire block is 0x00.
REGN (length 65536): Didn't occur earlier, but follows same pattern as earlier portions. Looks like it really should have been run through some sort of run-length encoding; it's runs of the same value for 12 or so bytes, and then a different value for the next stretch, and so on.
HIDN (length 65536): Entire block is 0x00.
BPAD (length 65536): Entire block is 0x00. NPAD (length 65536): Sporadic data runs. Unknown.
SCEN (length 384): Last chunk. Contains various small integers, as well as the strings "Scenario" and "GreenSarge1". This may correlate to something in the rest of the game.

bootcamp.ATL is similar:
FORM (not length prefixed): 0x6e440600 // another format specifier
TILEVERS (length 8): 0x01000000 0x00000000 // version information
THDR (length 20): contained values are 16, 16, 1600, 32, and 0x00ffff00.
What follows is information about the body of the file. The first information is "DIB 6D". This indicates that it's likely going to be a Device Independent Bitmap file, as is confirmed two bytes later with "BM6D", which seems to be a variant of BMP's "BM4D" magic number. If we dump that part (and the rest of the file) to a new file and give it a .bmp extension, this image pops up: http://imgur.com/YnV8p9J - It looks like it's some sort of tileset. The format isn't quite bmp, but it's close enough that it was within the tolerances of imagemagick.

rifleman.ani: No clue about any of it.

/r/ReverseEngineering Thread Link - mediafire.com