Text Data Encryption

JIM · Post by **JIM** » Sat Mar 08, 2008 9:34 am

As there are a number of text based adventure’s in production. I’ve being wondering how do some of the large level 9 adventures encrypt there word data and any picture data?

Sat Mar 08, 2008 11:10 am

It's compressed rather than encrypted...

I found a little bit of info here: http://l9memorial.if-legends.org/html/austin.html

To squeeze what was orginally a 200K mainframe program into 32K, and then to add an extra 70 locations just for the fun of it, was no mean feat. Pete's text compressor has been a feature of all Level 9's mammoth adventures. It works by running through all the messages and searching for common strings. For example, "ing" might occur frequently. The compressor replaces "ing" with a single code wherever it occurs. That done, it goes through again, and again, each time saving more space. "It doesn't always pick up what you'd expect it to," explains Pete. In the phrase "in the room" the compressor might decide that it was more efficient to use a code for "n th" and "e r" rather than pick out "in" and "the". That is not something which occurs to the human mind. The system has been rewritten to create graphics as well. Level 9 can now store a picture in about 30 bytes, using a similar method to the text compressor. That means a 200 location adventure - the minimum Pete will allow - can have a picture for each location for only another 6K of RAM. Not content with these two areas, the a-code compiler even compacts Basic program lines. "Most Basic systems have keywords which use a single byte," explains Pete. "We go further. We take out the arguments so that each Basic instruction only uses two or three bytes."

Dreamland Fantasy · Post by **Dreamland Fantasy** » Wed Mar 12, 2008 12:12 pm

Run length encoding (RLE) can be quite efficient at compressing BBC Micro images.

As an example, say your picture has a lot of black (colour 0) in it, looking at the raw data would show a lot of zeroes. Run length encoding will look at the "run" of the same numbers and count how many there are and then encode it something like 'count, value'. Something like '0,0,0,0,0,0,0,0' in this case would encode to '8,0'.

My explanation is perhaps a bit simplistic, but you should at least get the idea behind it.

Kind regards,

Francis.

Dreamland Fantasy · Post by **Dreamland Fantasy** » Wed Mar 12, 2008 3:01 pm

For the text adventure that I am currently writing I've chosen to store the text information in a separate (uncompressed) encrypted data file. This has the advantage of being able to store as much text as the floppy can handle rather than what you can fit into the BBC's memory. The only information held constantly in memory is the index of where everything is in the file.

The only downside of this method is that it is useless for games stored on cassette tape.

Kind regards,

Francis.

ghbearman · Post by **ghbearman** » Thu Mar 13, 2008 1:51 pm

If you compressed the data, you'd be able to store twice as much information on the disk

Dreamland Fantasy · Post by **Dreamland Fantasy** » Thu Mar 13, 2008 8:09 pm

@ghbearman

True, but my adventure at the moment is quite small and doesn't really need compressing.

My plans are to hopefully use this game as a stepping stone for bigger projects where I would definitely need to employ text compression.

Kind regards,

Francis.

AJW · Post by **AJW** » Thu Mar 13, 2008 10:27 pm

I used disk access of text together with 6 bit letter storage and abbreviations/single letters for commonly used words for Dominion. I don't know if Level 9's description of their text compression was bravado but I wondered how they managed to get so much into a single load and with such reported reduction in size. I think I managed about 60%!

kranser · Post by **kranser** » Mon Mar 17, 2008 1:42 am

What about packing methods for text?

I think characters that are normally used can be packed into less than 8 bits a character. Bit 7 can be ignored and (for letters a-z) bit 5 is always 1. However, packing limits what characters can be used in the game text.

Anyone know any packing methods that can be used, and that work ok for adventure games?

Kranser.

jon28 · Post by **jon28** » Mon Mar 17, 2008 2:50 am

I recall reading an article in one of the BBC magazines about text compression in adventure games, in one of the adventure columns I think.

If I remember correctly it described one method where you'd compress on a character by character basis, with the most used characters stored in a single bit and others in three bits. Except bits isn't the right word, I'm talking about one character of a hex value (ie &DE would be split as D and E).

So 0 through E would represent the 15 most popular characters and F would flag the next two bits would be the next character. Does that make sense?

Kecske Bak · Post by **Kecske Bak** » Mon Mar 17, 2008 8:08 am

I remember the magazine "Your Computer" after it went all yuppy with a square spine and about three pages an issue ran a long series about adventure programming on the BBC. If anyone has them it might be good to get scans of those to Jim.

Dreamland Fantasy · Post by **Dreamland Fantasy** » Mon Mar 17, 2008 9:23 am

If you have access to the INPUT series of magazines there are programs for (de)compressing text in there specifically for text adventures.

If you don't have access I could scan the relevant pages.

Kind regards,

Francis.

AJW · Post by **AJW** » Mon Mar 17, 2008 8:10 pm

kranser wrote:What about packing methods for text?

I think characters that are normally used can be packed into less than 8 bits a character. Bit 7 can be ignored and (for letters a-z) bit 5 is always 1. However, packing limits what characters can be used in the game text.

Anyone know any packing methods that can be used, and that work ok for adventure games?

Kranser.

I think that's what I said above. Used 5 bits and bit 6 to denote case IIRC.