Newsgroups: rec.arts.int-fiction
Path: gmd.de!jvnc.net!yale.edu!spool.mu.edu!agate!pasteur!cory.Berkeley.EDU!librik
From: librik@cory.Berkeley.EDU (David Librik)
Subject: Re: Encrypted hints
Message-ID: <librik.723862760@cory.Berkeley.EDU>
Sender: nntp@pasteur.Berkeley.EDU (NNTP Poster)
Nntp-Posting-Host: cory.berkeley.edu
Organization: University of California, at Berkeley
References: <librik.723701575@cory.Berkeley.EDU> <1992Dec7.090513.672@nwnexus.WA.COM> <1992Dec8.154640.10324@pollux.lu.se> 	<1992Dec8.163209.29880@Princeton.EDU> <9561927@MVB.SAIC.COM>
Date: Wed, 9 Dec 1992 00:59:20 GMT
Lines: 63

Whitten@Fwva.Saic.Com writes:

>jacobw@phoenix.Princeton.EDU (Jacob Solomon Weinstein) writes:
>> I wouldn't want to decode thirteen pages of
>>hints encoded in my cypher, but the letter-reversal thing would make
>>reading them pretty easy.
> 
>The problem with any encryption scheme is shown by the example of 
>David Librik:
> 

No.  The problem with my example was that I forgot to proofread it after
doing the encryption by hand at three in the morning, while reading news.
Oops, sorry, mea culpa.

If you are actually going to prepare a hint booklet, you should write a
little program to do the encryption.  (Someone kindly sent me one, actually.)

The letter-reversal approach people have been discussing is pretty cool.
Its only problem is that it may be so easy that people get to the point
where they can read it without effort.  A cipher takes a bit longer: I find
that a sentence takes me about a minute.

If you have to read thirteen pages of hints, something's wrong with your game.
Hints should be used sparingly, when you get stuck.

One problem with this cipher method of encoding hints is that it discourages
prolixity in hints; the Infocom InvisiClues allowed you to easily get long
sentences of hints out.  By-hand decryption encourages terseness: you give
only what the person needs to know.  Also, you put the necessary things in
order, so the person can stop decoding when they find something new to do.
Using numbers-for-words (the Scott Adams technique) lets you get sentences
quicker, but still maintains a lot of secrecy, especially if you fluff up
the "word list" with lots of bogus words that are never referenced.

> 
>Since this is so simple, depending on the difficulty of translation to
>hide a clue is pretty silly (IMHO), so the easy temptation is for the adventure
>writer to include the program from the command line.  This means the
>difficulty reduces to requiring the user to type the encoded text into some
>computer program (either the adventure itself or the one they wrote themselves)

I don't follow you.  The hints are on paper, and the player decodes them by
hand.  Sorry for not doing the encryption properly.  If the player wants to
write a BASIC program to do the translation for him -- well, all well and good,
he's spoiling the game for himself.  But it takes an effort -- remember that
the "security" here is not to protect the hints from "unauthorized" discovery,
but as a convenience to the player.  That's why it doesn't matter whether
your player is a "genius kid out there that can easily remember 53 was the
word 'zorch' at the last time it was used" -- if that kid has such a good
memory that they can unconsciously read encoded text even when they don't want
to ... well, let me suggest a career in languages.

>If you must use a CODE to PLAIN scheme, I encourage you to at least change
>correspondences for each page of the hint book, and to have the scheme be
>reflective ie: A -> S and S -> A.  This cuts down on the confusion level
>when doing the translation by hand...

I would strongly recommend that you not do the encryption by hand.  Look where
it got me.

- David (chastened) Librik
librik@cory.Berkeley.edu
