TADS 2.0 available on ftp.gmd.edu

4 views
Skip to first unread message

David Baggett

unread,
Dec 6, 1992, 2:39:38 PM12/6/92
to
I've just uploaded the TADS 2.0.7 shareware distribution from the High
Energy BBS to the if-archive at ftp.gmd.de in programming/tads. Both
the Mac and PC versions are there. I will keep these copies up to date
with the latest High Energy distribution. (There have already been a
few changes since the first batch of 2.0's went out.)

Have fun, and register if you use it!

Dave Baggett
--
d...@ai.mit.edu MIT Artificial Intelligence Laboratory
ADVENTIONS: interactive fiction (text adventures) for the 90's!
d...@ai.mit.edu *** Compu$erve: 76440,2671 *** GEnie: ADVENTIONS

David Baggett

unread,
Dec 6, 1992, 3:26:24 PM12/6/92
to
OK guys, I know you're hoarding Infocom game walkthroughs out there
somewhere. We can do a lot better than the 4 we have on ftp.gmd.de! I
checked risc.ua.edu and they don't have many either.

Surely people have good walkthroughs for the Zorks, Planetfall, etc.
Please email them to me or upload them to ftp.gmd.de so we can
consolidate everything in one place.

One idea is to agree on the format for walkthroughs and then have
people volunteer to do one each. That way we could take advantage of
the massively parallel nature of Usenet to get a nice, definitive suite
of solves. I think Kevin's UU2 solve is a good example to follow.
(It's on ftp.gmd.de in if-archive/solutions.)

I realize some people may not like the idea of solves, but I, at least,
would very much like to read through the all the Infocom games --
especially the LTOI2 games, most of which I haven't played -- even if I
don't actually play them. (Yes, this is less fun, but there's no way I
can find time these days to get through 15 complete games, and just
reading the text would be moderately enjoyable.)

Those of us who are IF game authors should know everything that's out
there pretty well so that we don't unknowingly use puzzles that have
already been done. (This is easier than you might think.) It's also
just a generally good idea to have a broad experience in the genre, I
think.

Walkthroughs could also be given accompanying reviews to help future
authors out. E.g., "Overall, the game was good, but I didn't like the
stupid maze, and there were too many ways to screw yourself by missing
things early on. The Zibbleknap puzzle was one of the best ever,
though!"

People could append their own comments to the archived copy so that
readers would get a wide sampling of opinion. Such data could be very
useful in the common discussions about subjective game design issues
like "should you have a maze," "how do you make a puzzle hard but not
frustrating," etc.

If IF games ever evolve to the point where they become of literary
interest, the solve/review file could also be a place for literary
analysis. I can imagine things like "the little dog that comes up
and bites your shin in the beginning of the game is really foreshadowing
your encounter with 12-headed Hellhound later in the game... The
inscription on the headstone in the graveyard is very reminicent of
Ode to a Grecian Urn, which suggests parallels between..."

(OK, so I'm fantasizing here. But I don't think such things are
out of the realm of possibility.)

Comments, questions, rude remarks?

Dave Baggett

PS> Though I only mentioned Infocom above, the same could be done for
other IF games too.

David Librik

unread,
Dec 6, 1992, 11:12:55 PM12/6/92
to
d...@xbar.ai.mit.edu (David Baggett) writes:
>Comments, questions, rude remarks?

I'll go you one better. I want to see real, useful hints for Infocom games.

In the old days of 8-bit computers, hint sheets for adventures were done
like this: the questions were in ordinary plain-text, the answers in a
simple letter-for-letter cipher (say A=Z, B=Y, etc.) and the cipher "key"
was plainly printed at the bottom of each page. You could read through
the hint book, find the problem you wanted an answer to, and then decode
the clue in a minute or so -- less if you use a computer program. Low-tech
as this might seem, it accomplishes EXACTLY what Lost Treasures of Infocom
fails to do: it lets you choose which hints you want without having to
read all the answers; unlike the "InvisiClues" invisible-ink approach, it is
reusable; and unlike the on-line "VisiClues" it's not so tempting for you
to just type "hint". I don't remember ever minding the decoding -- I mean,
you only ask for the clues when you're really stuck, in which case you don't
mind the minute or two it takes to decode the hint.

Scott Adams' hint books used a similar approach that worked a bit faster:
each game had a huge list of words, all indexed by numbers. The hints looked
like:
How can I get past the Guardian?
- 105 27 83 56 114 65 10 98 150 3
- ... more hints if necessary ...
You looked up the numbers in the word list and decoded the message. There were
more words than were necessary in the word-list in order to keep you from
reading the list to figure out the game -- not like it was possible, we're
talking about a big random list of words here.

The effect of both of these systems was not to make it hard on the user to find
hints, but to keep you from accidentally finding stuff out that you didn't
want to know. The LTOI "plain text hints" approach really stinks -- simply
by opening the hint book to a page, I subconsciously read the page and
spoil the game.

Sometimes low-tech is the right answer. Print out the hint files, and decode
the hints you want, when you need them.

What do you think? Would you welcome "hint books" in a simple code like this?
I'd love to have the Infocom LTOI hint book transcribed like this: I'd pitch
the original immediately. I haven't done it yet because I don't want to spoil
all the games for myself.

- David Librik
lib...@cory.berkeley.edu

James Jennings

unread,
Dec 7, 1992, 4:05:13 AM12/7/92
to
I think that encoding hints with an "a=z" cypher would be a royal pain.
It seems to me that any one encription scheme will be harder for some
people to use than others. Some people could transcribe an "a=z" cypher
in their head (I can't) while other's would be sufficently baffled if
the answers were only written backwards.

I, for one, never minded the on-line hints that the later Infocom games
used. I don't really understand those who say that they are too easy to
read.

But the hints in LTOI I are too easy to read.

Just my 0.02 Zorkmids. ;-)

James

Kjetil Torgrim Homme

unread,
Dec 7, 1992, 5:36:07 AM12/7/92
to
I think Magnetic Scrolls had the perfect solution in their games ("The
Pawn", "Guild of Thieves" ...). In the booklet, there was coded hints, like:

What does the Guru want?
12 24 54 43 84 64 42 73 99 41 72 ...

65 56 22 91 67 11 32 43 ...

You would have to type these in to the game, and it would spit out the
answer *if* you had progressed far enough... The hints were very good
too, ranging from uselessly cryptic to blindingly obvious :-)


Kjetil T.

Whi...@fwva.saic.com

unread,
Dec 7, 1992, 12:53:35 PM12/7/92
to
I like this approach, (or the modified one which has the numbers the word
numbers from a word list listed in the back of the book.

This would allow the adventure program to store the word list and do the
look up for you if you need it to.

I also liked the idea of "progressive unveiling" of hints available in
some adventure I used to play.
Instead of giving you the answer outright, the first few levels of hints
were in the form of some of the minor spoilers I've seen here on the 'net.
IE: instead of actually answering the question, it would ask you a question.

EG:
How can I get past the troll?

HINT1: Do trolls live in well lighted places?
HINT2: Did you find out what the glow worm was used for?
HINT3: Did you try to 'light the glow worm' ?
HINT4: Take the glow worm, Light the glow worm, and walk past the troll
while he is still blinded.

I just realized in writing this out, that if you actually stored the
hints as part of the game, the best way to make the most obvious hint
would be from some structure which stores the entire solution to the game.

Now, having that structure in the game is a Good Thing. If we add a capability
to the system to allow queries to that "data base" (also called hints) then
we can solve the problem with even the encrypted hints. Namely: the question
must be written in plain English.
Even having the questions written out gives some people too many hints about
a game, spoiling it for them.

I don't read too fast, but I have on more than one occasion picked up more
than I wanted to know about the next problem, simply by finally giving up
and looking for a solution to the previous problem.

Having an embedded 'solve' structure actually stored in the game also means
we can get away from the rigid lock step approach to I-F as well, since
there can be problems and solutions which come about from entirely different
ways of making particular decisions...

IE: If you break the padlock with the axe, there is no way you can
reuse the padlock to lock the lion in its cage...

Dave (whi...@fwva.saic.com) US:(619)535-7764 [I don't speak as a company rep.]

Phil Goetz

unread,
Dec 7, 1992, 5:29:31 PM12/7/92
to
If you write a walkthrough, please remember that it isn't useful to those
of us without the game unless you describe what is happening at each
point, and what the motivation for each action is. Only this way can
we know what the puzzles in a piece are.

The usual walk-through, which looks like "Drop wand. E. Get bird. E.
Drop cage. E. Plugh." doesn't express the fact that the want frightens
the bird, or that the bird frightens the dragon, or what Plugh does.

Phil
go...@cs.buffalo.edu

David Librik

unread,
Dec 7, 1992, 8:39:13 PM12/7/92
to
jenn...@halcyon.com (James Jennings) writes:

>I think that encoding hints with an "a=z" cypher would be a royal pain.
>It seems to me that any one encription scheme will be harder for some
>people to use than others. Some people could transcribe an "a=z" cypher
>in their head (I can't) while other's would be sufficently baffled if
>the answers were only written backwards.

Well, come up with a cipher that people can't do in their heads. That's
not too tough. As for "a royal pain" -- that's why the cipher key was
printed at the bottom of every page.

Yes, it takes time to decode. But the only times you ever need to decode
a hint are when you're really stuck.

Note that this approach is the opposite of the sort of "walkthrough" that
Dave Baggett wants -- these are individual hints, and the idea is to make
it difficult for you to read any answers without really trying. What Dave
wants is a way to read over the game, with commentary, if you're not planning
to play it. (I can see it catching on: "The Alienated Robot of Kalamontee:
A Post-structuralist Deconstruction of the Neo-Colonialist Subtext in
_Planetfall_")

Think of it this way: you've just spent the last four hours trying to get
past the Guardian in UU1. You have a piece of paper printout with the
following text on it:

VEHO SD KGKI GSDR DRO VKCF. NHZF SD SY DRO XKVV. ECO DRO CGZBT SY

DRO LZBSYQ BZZW PZB VSWXD.

and down at the bottom of the page is written:

CODE: A B C D E F G H I J K L M N O P Q R S T U V W Y Z
PLAIN: Q R S T U V W X Y Z A B C D E F G H I J K L M N O

--------------------------------------------------------------------

For hints in new games, I really like the idea that was proposed earlier of
a set of numbers (found in the hint book) that you type to the program, and if
you've gone far enough in the game it will give you the hint. In both cases,
the effort the player has to make -- small, but present -- deters him from
just "hint"ing his way through the game, but lets him get the answers when
he's really stuck.

The worst solution to this is the one in Lost Treasures of Infocom: there
needs to be SOMETHING to keep you from seeing all the answers as soon as
you open the book!!

- David Librik
lib...@cory.Berkeley.edu

David Baggett

unread,
Dec 8, 1992, 12:02:26 AM12/8/92
to
In article <BywuH...@acsu.buffalo.edu> go...@acsu.buffalo.edu (Phil Goetz) writes:
>The usual walk-through, which looks like "Drop wand. E. Get bird. E.
>Drop cage. E. Plugh." doesn't express the fact that the want frightens
>the bird, or that the bird frightens the dragon, or what Plugh does.

Actually I think both kinds are useful.

Administrative note: Upload the prose kind as game.txt and the
step-by-step kind to game.stepsolution. FTP *your* contributions to
ftp.gmd.de: if-archive/solutions.

And if you're *looking* for IF solutions we've already got a bunch on
there, thanks to Adam's giving me a pointer to another site that had
them.

Dave Baggett

David Baggett

unread,
Dec 8, 1992, 12:33:23 AM12/8/92
to
In article <BywuH...@acsu.buffalo.edu> go...@acsu.buffalo.edu (Phil Goetz) writes:
>The usual walk-through, which looks like "Drop wand. E. Get bird. E.
>Drop cage. E. Plugh." doesn't express the fact that the want frightens
>the bird, or that the bird frightens the dragon, or what Plugh does.

Ah, reading this note again reminded me: You can't actually have a
walkthrough like this for Colossal Cave because there are events that
happen randomly. An early example is the first dwarf, who throws an
axe at you. The time when he does this varies from game to game, and
you *must* get the axe to survive to the end. In fact, whether or not
you can get all 350 points is a matter of luck too -- if the pirate
doesn't happen to steal your treasure before your lamp runs out, you're
screwed, because his "booty" won't be in the maze!

You may be wondering why on Earth I remember this in such detail. Can
you say, "TADS version of Colossal Cave, distributed with complete
source code?" I knew you could!

I'm just putting on the finishing touches. Look for it here soon!

Lars J|dal

unread,
Dec 8, 1992, 3:19:00 AM12/8/92
to
d...@case.ai.mit.edu (David Baggett) writes:
>[...]

>You may be wondering why on Earth I remember this in such detail. Can
>you say, "TADS version of Colossal Cave, distributed with complete
>source code?" I knew you could!

>I'm just putting on the finishing touches. Look for it here soon!

Great! A "Colossal Cave" with a TADS parser and distributed code so
you can cheat if you really have a problem (shame on me for the
thought, but I never found out about the dark place).
And, least but not less, another complete game source code to get
ideas from.

>Dave Baggett
>--
>d...@ai.mit.edu MIT Artificial Intelligence Laboratory
>ADVENTIONS: interactive fiction (text adventures) for the 90's!
>d...@ai.mit.edu *** Compu$erve: 76440,2671 *** GEnie: ADVENTIONS

+--------------------------------------------------------------------------+
| Lars J|dal | Q: What's the difference between a quantum |
| email: prot...@daimi.aau.dk| mechanic and an auto mechanic? |
| or: joe...@dfi.aau.dk | A: A quantum mechanic can get his car into |
| University of Aarhus | the garage without opening the door. |
| Denmark | -- David Kra |
+--------------------------------------------------------------------------+

Jonathan R. Ferro

unread,
Dec 8, 1992, 12:55:43 AM12/8/92
to
@begin(LARGE-COMMA-ROUND-COMMA-AND-VERY-UNHAPPY-EXCLAMATION-POINT)

OK, one more time...

This is your brain:
[ picture of egg ]

This is your brain thinking about PLAYING adventure games:
[ picture of egg looking at rec.GAMES.int-fiction ]

This is your brain thinking about WRITING adventure games:
[ picture of egg looking at rec.ARTS.int-fiction ]

This is your brain posting just ONE more followup to a thread about
PLAYING adventure games to a group intended for WRITING adventure games:
[ picture of egg, poached inside the shell from the heat of
personal flames, being loaded into a mortar and *plonk*ed
over the horizon ]

GOT IT??

@end(LARGE-COMMA-ROUND-COMMA-AND-VERY-UNHAPPY-EXCLAMATION-POINT)

-- Jon Ferro Einsprachigkeit ist heilbar

Russell L. Bryan

unread,
Dec 8, 1992, 10:19:20 AM12/8/92
to
In article <kf93XTq00...@andrew.cmu.edu> Jonathan R. Ferro,

jf...@andrew.cmu.edu writes:
>This is your brain posting just ONE more followup to a thread about
>PLAYING adventure games to a group intended for WRITING adventure games:
> [ picture of egg, poached inside the shell from the heat of
> personal flames, being loaded into a mortar and *plonk*ed
> over the horizon ]

If one more person decides that he knows best what belongs in each
newsgroup,
I'm going to have a small but effective fit.

If you read the preceding articles with any depth, you might notice that
we are discussing the best way to provide hints. Now who do you suppose
would provide hints and clues and maps?

I'll give YOU a hint: It's not the guy who just picked up the game from
his
favorite FTP site.

It's the developers who write the damn games and hint books in the first
place!
There's nothing worse than someone who only posts when he's
complaing about other people's posts. Get constructive. Take up a hobby.
I hear that thinking is coming back into fashion.

Now, anyway, as to the hint deal -- I whole-heartedly agree that the LTOI
method failed. Personally, I'm considering implementing a hint method
into
my game where the hints are online AND encoded. I believe that such a
system could be implemented into TADS -- perhaps as a user exit. A module
of the Scott Adams number-to-word hint method mentioned earlier could
actually
be transferrable between games, sort of an "advhint.t" #include file.

-- Russ

Magnus Olsson

unread,
Dec 8, 1992, 10:46:40 AM12/8/92
to
In article <1992Dec7....@nwnexus.WA.COM> jenn...@halcyon.com (James Jennings) writes:
>I think that encoding hints with an "a=z" cypher would be a royal pain.
>It seems to me that any one encription scheme will be harder for some
>people to use than others. Some people could transcribe an "a=z" cypher
>in their head (I can't) while other's would be sufficently baffled if
>the answers were only written backwards.

One suggestionm, which I personally like, is to just transpose pairs of
letters. In a word with an odd number of letters, the last letter is
left as it is.

An example (done on the spot, in my head):

Htsi nercpyitno emhtdo si erlayl aeys ot od ni no'es ehda, ub tslil
usffcieitnyl boufcstade ot eb on-nrtviail.

Magnus Olsson | \e+ /_
Department of Theoretical Physics | \ Z / q
University of Lund, Sweden | >----<
mag...@thep.lu.se, the...@seldc52.bitnet | / \===== g
PGP key available via finger or on request | /e- \q

David Baggett

unread,
Dec 8, 1992, 11:01:39 AM12/8/92
to
In article <kf93XTq00...@andrew.cmu.edu> "Jonathan R. Ferro" <jf...@andrew.cmu.edu> writes:
>@begin(LARGE-COMMA-ROUND-COMMA-AND-VERY-UNHAPPY-EXCLAMATION-POINT)

>This is your brain posting just ONE more followup to a thread about
>PLAYING adventure games to a group intended for WRITING adventure games:
> [ picture of egg, poached inside the shell from the heat of
> personal flames, being loaded into a mortar and *plonk*ed
> over the horizon ]

You've already sent this to half the people who post here regularly in
email. Besides, the point of the walkthroughs posting was that a new
IF archive is starting (which is of great interest to writers and
players alike), and Volker and I want to get it well-stocked.

I wasn't making an idle remark when I said I think IF game authors
should be as well-read as possible in the genre. The problem with IF
is that it can take a month to get through a "work;" so it would be
nice to have *solid* walkthroughs that would let busy people read
through the text of a game from start to finish without having to
figure out the puzzles on their own. This isn't "playing," it's "doing
research."

David Baggett

unread,
Dec 8, 1992, 1:38:51 PM12/8/92
to
In article <1992Dec8.1...@pollux.lu.se> mag...@thep.lu.se (Magnus Olsson) writes:
>Htsi nercpyitno emhtdo si erlayl aeys ot od ni no'es ehda, ub tslil
>usffcieitnyl boufcstade ot eb on-nrtviail.

oNt noyl si htsi erlayl ogdo ofr ihtns, tis' otatlly oclo htta eppoel
acn edichpre htsi tsfuf ni htier ehdas os qiukcyl. (mH,m onw hwta odse
htta asy bauto uhamn ivusla rpcoseisgn?)

I ovet ofr htis noe, aMngsu! (lPsu, tis' aeys ot od iwht mEcas ro iv!)

aDev aBggtet

Adam Justin Thornton

unread,
Dec 8, 1992, 1:34:10 PM12/8/92
to
In article <1992Dec8.1...@pollux.lu.se> mag...@thep.lu.se (Magnus Olsson) writes:

>Htsi nercpyitno emhtdo si erlayl aeys ot od ni no'es ehda, ub tslil
>usffcieitnyl boufcstade ot eb on-nrtviail.

Cautlayl, tis' rtviail. Even to read on first glance. Harder to write though
:-).

Adam
--
"And in the heartbreak years that lie ahead, |++| ad...@rice.edu |++| Cthulhu
Be true to yourself and the Grateful Dead." --Joan Baez | 64,928 | fthagn!
"Very often, a common stone, thrown away and despised, is worth more than
a cow." -- Paracelsus | If these were Rice's opinions I'd shoot myself.

Jacob Solomon Weinstein

unread,
Dec 8, 1992, 11:32:09 AM12/8/92
to
mag...@thep.lu.se (Magnus Olsson) writes:
>One suggestionm, which I personally like, is to just transpose pairs of
>letters. In a word with an odd number of letters, the last letter is
>left as it is.
>
>An example (done on the spot, in my head):
>
>Htsi nercpyitno emhtdo si erlayl aeys ot od ni no'es ehda, ub tslil
>usffcieitnyl boufcstade ot eb on-nrtviail.

Hmmm... Interesting. I think that what scheme one picks depends largely
on what sort of obstacles one wants to place in the path of the
clue-reader. I tend to be the type of player who refers to hints too
often, and then curses himself for it. As a result, I want the hints for
my upcoming game _Save Princeton_ to be a bit of a pain to lessen the
temptation. I'm therefore putting it in a "a=z, b=a, c=b" cypher,
which is just about the level of difficulty I would want if I were
using the hints.

But it occurs to me that I might be in the minority, and that most
players might have more will-power than I do. So, what do you all think?
Would you rather have the hints just encrypted enough that you won't
accidentally read them, or sufficiently difficult that you will only
use them when you really need them? And is it better to err on the side
of difficulty, or on the side of ease?

One thing in favor of ease: if the hints are well-written, reading them
after you've solved the game should be fun. Magnus's suggestion is
perfect in this respect; 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.

Paul D. Smith

unread,
Dec 8, 1992, 10:57:06 AM12/8/92
to Phil Goetz
[] Regarding Re: Walkthroughs;
[] go...@acsu.buffalo.edu (Phil Goetz) writes:

pg> If you write a walkthrough, please remember that it isn't
pg> useful to those of us without the game unless you describe
pg> what is happening at each point, and what the motivation for
pg> each action is. Only this way can we know what the puzzles in
pg> a piece are.

pg> The usual walk-through, which looks like "Drop wand. E. Get
pg> bird. E. Drop cage. E. Plugh." doesn't express the fact that
pg> the want frightens the bird, or that the bird frightens the
pg> dragon, or what Plugh does.

While that may be true, I personally find the "extraneous text"
walkthroughs extremely annoying for those of use *with* the game
(although I admit I've never used a walkthrough :).

If you have the game, then (IMHO) the walkthrough should be just
straight commands. When you type them into the game, you'll see what
happens.

With all the extra gobbledygook half the time you know what's going to
happen by reading the walkthrough, and the surprise is ruined.

I have a small, but growing, cache of walkthroughs which are *pure*
commands, with the only text in places where random events occur.
I'll be uploading them to the IF ftp archive on ftp.gmd.de soon...
--

paul
-----
------------------------------------------------------------------
| Paul D. Smith | paul_...@dg.com |
| Data General Corp. | p...@lemming.webo.dg.com |
| Network Systems Development Division | |
| Open Network Systems Development | "Pretty Damn S..." |
------------------------------------------------------------------

Whi...@fwva.saic.com

unread,
Dec 8, 1992, 6:40:03 PM12/8/92
to
jac...@phoenix.Princeton.EDU (Jacob Solomon Weinstein) writes:
>Hmmm... Interesting. I think that what scheme one picks depends largely
>on what sort of obstacles one wants to place in the path of the
>clue-reader. I tend to be the type of player who refers to hints too
>often, and then curses himself for it. As a result, I want the hints for
>my upcoming game _Save Princeton_ to be a bit of a pain to lessen the
>temptation. I'm therefore putting it in a "a=z, b=a, c=b" cypher,
>which is just about the level of difficulty I would want if I were
>using the hints.
> 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:


>
>Think of it this way: you've just spent the last four hours trying to get
>past the Guardian in UU1. You have a piece of paper printout with the
>following text on it:

> VEHO SD KGKI GSDR DRO VKCF. NHZF SD SY DRO XKVV. ECO DRO CGZBT SY

> DRO LZBSYQ BZZW PZB VSWXD.

>and down at the bottom of the page is written:

> CODE: A B C D E F G H I J K L M N O P Q R S T U V W Y Z
> PLAIN: Q R S T U V W X Y Z A B C D E F G H I J K L M N O


If anyone else tried to convert his example, they noticed:
1) the mapping isn't reflective A-> Q but Q -> G.

2) this particular example doesn't have any way to "encode" the letter P.
nor does it have a 'code' for X.

3) If you use the code as given it produces the PLAIN TEXT of:

LUXE IT AWAY WITH THE LASV. DXOV IT IN THE XALL. USE THE SWORJ IN

THE BORING ROOM FOR LIMXT.

Now this is not intended to be a flame, but rather an observation.
The simplest way to convert an arbitary CODE to PLAIN character mapping
is to write a program. In fact, I tried three times to convert this message
without one and kept getting confused between the CODE and PLAIN line.

The fact that there were problems with the "plain text" just increased my
confusion. I eventually gave up, wrote the following program in MUMPS,
and just let the computer do the work.

READ "CODE: ",IN,!
WRITE "PLAIN: "
FOR IDX=1:1:$LENGTH(IN) DO
.SET CH=$EXTRACT(IN,IDX)
.WRITE $TRANSLATE(CH,"ABCDEFGHIJKLMNOPQRSTUVWYZ ","QRSTUVWXYZABCDEFGHIJKLMNO ")
WRITE !
QUIT

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)

The number + word table method seems much more secure. It is a lot harder to
create a program to do the translation for you, and if you don't have a one to
one mapping from words to numbers, you can slow the genius kids out there that
can easily remember 53 was the word 'zorch' at the last time it was used.

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...

Just my 0.02 Zorkmids worth...

Peter Weyhrauch

unread,
Dec 8, 1992, 5:33:08 PM12/8/92
to
Hi, all.

I was recently playing BORDER ZONE, and I found the on-line unveiling
of hints to be very nice. It gives you more satisfaction if you can
solve the puzzle with just a little help than with a dead giveaway.

It was Dave (whi...@fwva.saic.com) who originally mentioned unveiling
hints in his post of the seventh:

QUOTE (slightly reformatted)


I also liked the idea of "progressive unveiling" of hints available in
some adventure I used to play. Instead of giving you the answer
outright, the first few levels of hints were in the form of some of
the minor spoilers I've seen here on the 'net. IE: instead of
actually answering the question, it would ask you a question.

EG: How can I get past the troll?

HINT1: Do trolls live in well lighted places?
HINT2: Did you find out what the glow worm was used for?
HINT3: Did you try to 'light the glow worm' ?
HINT4: Take the glow worm, Light the glow worm, and walk past the
troll while he is still blinded.

UNQUOTE

BORDER ZONE uses unveiling to hide the clues, but there is a related
problem that isn't solved: it lets you see the full list of questions.
This somewhat spoiled the story by letting you know about future
elements. I would propose a double unveiling. Let the questions be
hidden as well, until you ask for the next one. However, this only
works well in a very linear story like BORDER ZONE. If there is no
logical next puzzle, your hint system might reveal the wrong one by
accident.

An a next step in on-line help, one of the things my drama system is
trying to do is model the user to the extent that it can detect when
the user is stuck. (I usually try to stay away from the puzzle-based
interactive fiction, but occassionally there are definite obstacles
that must be overcome.) If the user is stuck, the drama then
automatically gives the user a hint, preferrably a subtle hint from
within the game.

Warning: very mild DEADLINE spoiler in my example.

For example, suppose the user needs to see the ladder (as in DEADLINE)
from the shed. The drama system could cause it to become windy, which
would make the shed door blow open and shut, perhaps drawing the user
into the shed. When the user sees the ladder, the solution may click
in the user's mind. As a more blatant clue, perhaps Haligan could at
some point use the ladder to climb on top of the shed itself. Both of
these are examples of giving hints within the game itself, which may
be ultimately a more satisfying way to get hints.

Peter Weyhrauch
Project Oz

Palmer T. Davis

unread,
Dec 8, 1992, 7:48:21 PM12/8/92
to

In a previous article, d...@case.ai.mit.edu (David Baggett) says:
>
>You may be wondering why on Earth I remember this in such detail. Can
>you say, "TADS version of Colossal Cave, distributed with complete
>source code?" I knew you could!
>
>I'm just putting on the finishing touches. Look for it here soon!

*ROFL* What a coincidence! I'm working on an ADVSYS version of
Colossal Cave in another window right now. You seem to be farther
along than I, but when finished the two taken together should be
a good illustration of the differences between the two languages.

Perhaps some third party might volunteer to write an ALAN version?

-- PTD --

(Hmm. Maybe I should suspend development until I see your implementation,
to ensure that our two versions are consistent.)
--
Palmer T. Davis ___
<pt...@po.cwru.edu> \X/ cthread. cthread_fork(). Fork, thread, fork!

Paul D. Smith

unread,
Dec 8, 1992, 1:27:01 PM12/8/92
to David Librik
[] Regarding Re: Encrypted hints ; you wrote:

dl> Well, come up with a cipher that people can't do in their
dl> heads. That's not too tough. As for "a royal pain" -- that's
dl> why the cipher key was printed at the bottom of every page.

Heck, I wrote a short program to do this; it's trivial. IMHO there's
no need for a complex cipher; a=z (or whatever) is fine. I mean, sure
some people could probably do it in their heads, but no one's going to
be able to look at the sentence and translate it instantly, just as if
it was plaintext.

As long as it's not immediately obvious, it serves the purpose IMHO.

Here's a simple encryption/decryption program. It should be very
portable. Use it as you like (or junk it :) Don't forget to strip my
.sig at the end; unfortunately inews adds it for me :(

For a brief description, decrypt the following :) -- try using:

% cat <txt> | ./hcrypt -

or, if you can cut/paste:

% ./hcrypt - > output
<paste text here>
% cat output

-26
:!7E59 9,0(8 , +/-3 ,7;A2(39 ,8 9:( )#789 ,7;G 9:(3 9:( 9(D9H 9:(
3A2.(7 <3> #8 ,??(? 94/8A.97,!9(? )742 (,!: !:,7 #3 9:( 9(D9G ,3? 9:(
7(8A19 #8 1440(? A5 #3 ,3 #39(73,1 9,.1( 94 ;(9 9:( 7(8A19H

!:,78 349 #3 9:( 9,.1( ,7( 1()9 ,143(H 9:( 4A95A9 #8 57()#D(? C#9:
9:( #3B(78( 45(7,9#43G 84 #9'8 8#251( 94 (3!7E59 (,!: :#39 C#9: ,
?#))(7(39 4))8(9 #) ?(8#7(?H

----- 8>< snip, snip ><8 ------------------------------------------------------
/* hcrypt.c - extremely simple encrypt/decrypt for text
*
* Copyright (C) 1992 Paul D. Smith
*
* hcrypt is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 1, or (at your option)
* any later version.
*
* hcrypt is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
* or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
* License for more details.
*
* To get a copy of the GNU General Public License, write to the Free
* Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include <stdio.h>
#include <ctype.h>

/*
* The text string contains the chars which will be encrypted;
* anything not in this string will be printed unchanged.
*
* Note that the digits and letters must come all together and in the
* proper order. Any other chars should be added with the
* punctuation, and can be in any order.
*/
#define TEXT "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ,.!?();:-#$"
#define TEXT_LEN (sizeof(TEXT)-1)

#define DIG_OFF 0 /* start of digits in TEXT */
#define ALPHA_OFF 10 /* start of letters in TEXT */
#define PUNCT_OFF 36 /* start of punctuation in TEXT */

extern int atoi();

int main(argc, argv)
int argc;
char *argv[];
{
char line[81];
char **cpp;
char *cp;
char *text = TEXT;
int offset, neg=0;

/*
* Make sure the command line looks reasonable...
*/
if ((argc < 2) || ((argc < 3) && strcmp(argv[1], "-")))
{
fprintf(stderr, "Usage: %s [- | +|-n <text> ...]\n", argv[0]);
exit(1);
}

/*
* Find the absolute value of the offset; set NEG if it's negative
* Set up to read from the command line, or from stdin.
*/
if (argc > 2)
{
cp = argv[1];
cpp = &argv[1];
}
else
{
fgets(line, 81, stdin);
for (cp = line; isspace(*cp) && (*cp != '\0'); ++cp)
{}
}

if ((cp[0] != '+') && (cp[0] != '-'))
{
fprintf(stderr, "%s: Invalid offset syntax: `%s'\n", argv[0], cp);
exit(1);
}

offset = atoi(&cp[1]);
if (offset > TEXT_LEN)
{
offset %= TEXT_LEN;
fprintf(stderr,
"%s: warning: offset too large--using mod of max (%d) = %d\n",
argv[0], TEXT_LEN, offset);
}
if (!offset)
{
fprintf(stderr, "%s: No conversion done: offset is 0\n", argv[0]);
exit(0);
}
if (cp[0] == '-')
neg = 1;

/*
* Print the decoding info...
*/
printf("%c%d ", neg ? '+' : '-', offset);

/*
* Now loop through the input, converting it as necessary.
*/
cp += 2;
while (isdigit(*cp))
++cp;
while (isspace(*cp))
++cp;

while (1)
{
int c;

/*
* Get the next char, either from the command line or stdin
*/
if (argc > 2)
{
if (*cp != '\0')
++cp;
else
{
if (*(++cpp) == NULL)
break;
cp = *cpp;
}

c = *cp == '\0' ? ' ' : *cp;
}
else
{
if (*cp == '\0')
{
if (fgets(line, 81, stdin) == NULL)
break;
cp = line;
}

c = *(cp++);
}

/*
* Figure out the char's offset in the TEXT array
*/
if (isalpha(c))
c = ((islower(c) ? toupper(c) : c) - 'A') + ALPHA_OFF;
else if (isdigit(c))
c = (c - '0') + DIG_OFF;
else
{
char *tp;

for (tp = text+PUNCT_OFF; (*tp != '\0') && (*tp != c); ++tp)
{}

/*
* If it's not in the array, then just print it and continue
*/
if (*tp == '\0')
{
putchar(c);
continue;
}
c = tp - text;
}

/*
* Encrypt and print it
*/
if (neg)
{
c -= offset;
if (c < 0)
c += TEXT_LEN;
}
else
c = (c + offset) % TEXT_LEN;

putchar(text[c]);
}

putchar('\n');
exit(0);
return (0);

David Librik

unread,
Dec 8, 1992, 7:59:20 PM12/8/92
to
Whi...@Fwva.Saic.Com writes:

>jac...@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
lib...@cory.Berkeley.edu

David Baggett

unread,
Dec 8, 1992, 8:17:57 PM12/8/92
to
In article <PDS.92De...@lemming.webo.dg.com> p...@lemming.webo.dg.com (Paul D. Smith) writes:
>While that may be true, I personally find the "extraneous text"
>walkthroughs extremely annoying for those of use *with* the game
>(although I admit I've never used a walkthrough :).

As I mentioned to Paul in email, I personally like both kinds. Paul's
favorite seems to have been given the type name "stepsolution," while
the prose kind are just "game.txt" Let's just follow this convention
and have both on ftp.gmd.de.

Dave Baggett

David Baggett

unread,
Dec 8, 1992, 8:24:32 PM12/8/92
to
In article <1g3fo...@usenet.INS.CWRU.Edu> pt...@po.CWRU.Edu (Palmer T. Davis) writes:
>*ROFL* What a coincidence! I'm working on an ADVSYS version of
>Colossal Cave in another window right now.
>
>(Hmm. Maybe I should suspend development until I see your implementation,
>to ensure that our two versions are consistent.)

The main rule that I'm following is, "If text existed in the original
for something, use it verbatim, otherwise make something consistent
up." Basically I want to retain the "purity" of the original, rather
than write a bunch of new prose.

The dwarves and pirate probably won't behave *exactly* like they did in
the original Fortran version -- the code is almost too gross to follow
at all. But pretty much everything else should be the same (except
that I've added zillions of "decorations" to make the game seem less
stupid about its environment, and, of course, a sentence parser, thanks
to TADS.)

Darin Johnson

unread,
Dec 8, 1992, 9:49:33 PM12/8/92
to
>If you have the game, then (IMHO) the walkthrough should be just
>straight commands. When you type them into the game, you'll see what
>happens.

But this type is very bad for use as hints, which should come
as no surprise. However, this is often the only form of hints
you can find for some games. For example, I recently needed
a hint for spellbreaker - my hintbook safely hidden away with
a friend who had just left the US for a month... So a found
a walkthrough, the only hints I could find for it. I was able
to not glance at anything else, but I did find out what to do,
and was confused for hours trying to figure out why it worked
and how I was supposed to figure this out within the game...

Plus, I don't even see what the need for a walkthrough would
be, other than hints. Except for someone who just wants to
borrow the game for an hour and run through it. But this seems
like such a small minority compared to people who would rather
have hints...
--
Darin Johnson
djoh...@ucsd.edu
"Only Nixon could go to China" -- Vulcan proverb

Adam Justin Thornton

unread,
Dec 9, 1992, 12:02:30 AM12/9/92
to
I ahev hcnaegd ym imdn. Htis si ifen.

Dama

Jacob Solomon Weinstein

unread,
Dec 8, 1992, 11:23:38 PM12/8/92
to
lib...@cory.Berkeley.EDU (David Librik) writes:
>
>jac...@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.
>
>If you have to read thirteen pages of hints, something's wrong with your game.
>Hints should be used sparingly, when you get stuck.
I don't quite understand your objection. My point in my original posting
was that, when the hints are well-written, it's fun to read through all
the hints AFTER you've solved the game. Clearly, anybody who would read
all thirteen pages of hints before solving the game would probably have
been better off just getting a walkthrough.

The reason my hint sheet is so long, by the way, is that I've followed
the old Infocom model of having a series of progressively more spoiling
hints for each puzzle.

Paul DuBois

unread,
Dec 9, 1992, 5:17:02 AM12/9/92
to
mag...@thep.lu.se (Magnus Olsson) writes:

>An example (done on the spot, in my head):

>Htsi nercpyitno emhtdo si erlayl aeys ot od ni no'es ehda, ub tslil
>usffcieitnyl boufcstade ot eb on-nrtviail.

I like it -- it's quick and easy to read as long as one concentrates a
little bit. Somewhat like watching a videotape in "fast" mode.

> Magnus Olsson | \e+ /_
--
Paul DuBois Permanent: p...@soda.berkeley.edu
If you call this a short .sig, you oppose its reality. If you do not call
it a short .sig, you ignore the fact. Now what do you wish to call this?

Todd R Johnson

unread,
Dec 9, 1992, 9:55:40 AM12/9/92
to

Encrypted hints seem pretty silly to me. If I want a hint, then give
it to me. Don't make me do cartwheels to get it. One way to encourage
the player to think before getting a hint is to layer a series of hints
from minor spoiler to major spoiler. The first time help is requested,
the minor spoiler is given. Then the game requires a certain number
of steps (or perhaps a certain variety of moves) before giving the
next spoiler.

Something like:

You're on a wide cobblestone street. To the north is the castle. To
south is an intersection filled with a crowd of noisy people.

>help
You wonder what the crowd of people are so excited about.

>help
You're not that incapable of action.

...other moves...

>help
You might be able to get a better view if you walk into the crowd.

Damien P. Neil

unread,
Dec 9, 1992, 11:28:07 AM12/9/92
to
In article <1992Dec9.1...@magnus.acs.ohio-state.edu> tjoh...@magnus.acs.ohio-state.edu (Todd R Johnson) writes:
>Encrypted hints seem pretty silly to me. If I want a hint, then give
>it to me. Don't make me do cartwheels to get it.

Yes, but in a hint book it is too easy to see a solution that you did not
want. Ever look at the LTOI hint books? Yech...
-----
Damien Neil dp...@po.cwru.edu "Until somebody debugs reality, the best
Case Western Reserve University I can do is a quick patch here and there."
CMPS/EEAP double majoring masochist - Erik Green

Russell L. Bryan

unread,
Dec 9, 1992, 11:42:56 AM12/9/92
to
Actually, one of my truly favorite hint methods was in the hint book for
Deep
Space Drifter (though I'm sure a similar method could be found elsewhere).
The hints were listed in a random order, and included minor spoilers and
major spoilers (about five hints per puzzle). You would find the puzzle
in
a list at the beginning, and be referred to the first hint. If that
didn't
work, you would be referred to another hint. To actually get to the final
spoiler, you would have to flip through seven pages five or six times, and
you would never know what the other hints on the page applied to without
having started from the beginning.

Such a method is good, but I've never been a lover of hard copy
documentation.

-- Russ

John Francis

unread,
Dec 9, 1992, 12:19:31 PM12/9/92
to
In article <1g3hg5...@life.ai.mit.edu> d...@case.ai.mit.edu (David Baggett) writes:
>In article <PDS.92De...@lemming.webo.dg.com> p...@lemming.webo.dg.com (Paul D. Smith) writes:
>>While that may be true, I personally find the "extraneous text"
>>walkthroughs extremely annoying for those of use *with* the game
>>(although I admit I've never used a walkthrough :).
>
>As I mentioned to Paul in email, I personally like both kinds. Paul's
>favorite seems to have been given the type name "stepsolution," while
>the prose kind are just "game.txt" Let's just follow this convention
>and have both on ftp.gmd.de.

My favourite "walkthroughs" consisted of a transcript of a game session.
(similar to the the output from a "SCRIPT" command in Infocom games).

In fact, in the proto-game-play-system I wrote about fifteen years ago
(on a DECSystem-20) I took this one stage further, as follows:
The transcript was a verbatim log of everything that appeared on the
terminal. In particular, the prompt character (usually ">") appeared
at the beginning of every line containing user input.
So, when I added the "OBEY" command to execute commands from a file,
I made it optionally only take notice of commands on a line prefixed
by the prompt character - all other lines would be treated as comments.
This meant that I could feed a transcript file straight back into the
game program as a command file with no editing necessary, even if the
game had been played at maximum verbosity.

Bear in mind I was used to playing games on a mainframe, not on a PC.
Capturing the output from (and feeding a list of commands to) a game
program was simplicity itself: all you had to do was run the program
over a pseudo-terminal. In fact, I probably still have the set of
command files I used while I was solving the original "dungeon" (aka
zork) - I certainly still have a hardcopy of the final transcript.
As such, adding an "OBEY" command was only making certain operations
rather more convenient, not adding any new functionality. Mind you,
I would probably still put such a capability into any game system I
wrote today - does TADS have this feature automatically built in?

P.S. Would anyone be interested in a TADS version of mainframe zork?
I keep on thinking about putting something like this together, and
it is becoming apparent that TADS is probably the way to go.
I'm talking about a version including everything up to the Don Woods
stamp - if anyone knows of puzzles added later than that one I would
be very interested to hear about them.
--
John Francis jo...@apollo.hp.com
with 9 cats to feed, I don't have time to think up a clever .sig

Tom O Breton

unread,
Dec 9, 1992, 5:06:07 PM12/9/92
to
>*ROFL* What a coincidence! I'm working on an ADVSYS version of Colossal
>Cave in another window right now. You seem to be farther along than I, but
>when finished the two taken together should be a good illustration of the
>differences between the two languages.
>
>Perhaps some third party might volunteer to write an ALAN version?

A fellow named Dave Gasior has also redone Colossal Cave, on AGT (used to be
GAGS)

Tom


--
The Tom spreads its huge, scaly wings and soars into the wild sky...
up... up... out of sight... (t...@world.std.com)

David Baggett

unread,
Dec 9, 1992, 7:33:29 PM12/9/92
to
In article <Bz05G...@apollo.hp.com> jo...@apollo.hp.com (John Francis) writes:
>[Making text games take scripts as input.]

>does TADS have this feature automatically built in?

Yeah, you can do that; it's incredibly useful for regression testing.
Actually I once proposed to Mike that he should just save a compressed
script for save files instead of the binary state information it saves
now. Upon loading, you'd just execute the commands in the saved script
in order without showing any text.

The only problem is this could get really slow if you had, say, 1500
turns done.

Magnus Olsson

unread,
Dec 10, 1992, 6:25:51 AM12/10/92
to
In article <Bz05G...@apollo.hp.com> jo...@apollo.hp.com (John Francis) writes:
>P.S. Would anyone be interested in a TADS version of mainframe zork?
>I keep on thinking about putting something like this together, and
>it is becoming apparent that TADS is probably the way to go.
>I'm talking about a version including everything up to the Don Woods
>stamp - if anyone knows of puzzles added later than that one I would
>be very interested to hear about them.


Depends on how different this version is from the Fortran version - the
latter has been translated to C, and exists in binary form for all the
machines that support TADS. If you're speaking of the original MDL
version, it would be just great.

Magnus Olsson

unread,
Dec 10, 1992, 2:20:10 PM12/10/92
to
In article <1ftktq...@life.ai.mit.edu> d...@xbar.ai.mit.edu (David Baggett) writes:
>I've just uploaded the TADS 2.0.7 shareware distribution from the High
>Energy BBS to the if-archive at ftp.gmd.de in programming/tads.

Thanks a *lot*! However, when I'd downloaded it, I found no docs in the
zip file, but the following message in the file READ.TAD:

}You should download the TADS Documentation archive, TADS2DOC.ZIP (on DOS)
}or TADS2DOC.SIT (on Macintosh) [note - these extensions may be changed if
}the sysop of your BBS or on-line service has repackaged the archive with
}a different compression tool]. This file contains overview documentation
}for TADS, as well as the source for "Ditch Day Drifter", a complete sample
}game.
}
}Additional documentation is available to registered users.

From this I draw the conclusion that it would be allowable to upload these
documentation files to ftp.gmd.de as well.

So, could somebody please do that?

Paul D. Smith

unread,
Dec 9, 1992, 6:00:47 PM12/9/92
to Darin Johnson
[] Regarding Re: Walkthroughs;
[] djoh...@cs.ucsd.edu (Darin Johnson) writes:

>If you have the game, then (IMHO) the walkthrough should be just
>straight commands. When you type them into the game, you'll see
>what happens.

dj> But this type is very bad for use as hints, which should come
dj> as no surprise. However, this is often the only form of hints
dj> you can find for some games.

dj> Plus, I don't even see what the need for a walkthrough would
dj> be, other than hints. Except for someone who just wants to
dj> borrow the game for an hour and run through it. But this seems
dj> like such a small minority compared to people who would rather
dj> have hints...

Hints is hints, walkthroughs is walkthroughs. I don't believe they
should overlap at all.

A hint is when you want to play the thing, but are so frustrated you
need help before you put some vital body part through your computer's
screen.

A walkthrough is when you *don't* want to play it, but you want to run
through it for some reason: you want to see the story but you don't
want to spend any time working at it. Or if you've finished the game
and just want to see how else it can be done.

I think with the newsgroups, hints files, etc. there's more than
enough places to obtain hints if a hint is what you want: it shouldn't
be necessary to resort to the walkthrough.

I kind of thought my "encrypt" program might be useful for encrypting
hints stored in the IF archive or something: since it can encrypt with
(currently) 40-odd different keys and you can easily store a different
key with each hint, you could theoretically run a large hint file
through the program and only successfully decrypt the hint you want...
or something.

Eric D. Shepherd

unread,
Dec 10, 1992, 2:42:13 PM12/10/92
to
I downloaded the TADS 2.0 for MS-DOS and the ZIP archive was damaged. A
few of the files came out okay, but none of the interesting ones did. Has
anyone actually managed to get this file unpacked? If so, I'll try the
download again.

- Eric S.

--
Eric D. Shepherd | Apple II Alliance Charter Member
InterNet: uer...@mcl.mcl.ucsb.edu | ACM Member
FidoNet: 1:206/2713 Eric Shepherd | Programming Law #1: "When in
AOL: Sheppy | doubt, rewrite from scratch."

David Baggett

unread,
Dec 10, 1992, 9:10:26 PM12/10/92
to
In article <uerics.724016533@mcl> uer...@mcl.ucsb.edu (Eric D. Shepherd) writes:
>I downloaded the TADS 2.0 for MS-DOS and the ZIP archive was damaged.

I just FTP'ed it and it unpacked fine with my Unix unzipper. Did you
transfer in binary mode?

Paul D. Smith

unread,
Dec 10, 1992, 1:32:34 PM12/10/92
to John Francis
[] Regarding Re: Walkthroughs;
[] jo...@apollo.hp.com (John Francis) writes:

jf> In article <1g3hg5...@life.ai.mit.edu> d...@case.ai.mit.edu
jf> (David Baggett) writes:

jf> My favourite "walkthroughs" consisted of a transcript of a
jf> game session. (similar to the the output from a "SCRIPT"
jf> command in Infocom games).

Just a note: I suspect that making freely available complete
transcripts for games covered under some kind of copyright would be a
violation of the copyright--I mean, you've basically provided the
whole game right there!

jf> [... discussion of OBEY command ...]

Infocom had a similar feature in the debugging versions of their
games; you could start to record a "command script file" (that's what
I call it) with the command #reco. It would basically write out each
command to a disk file. You ended the recording with #unre.

You could then cause the game to "run" a command script file with the
command #comm: it would read and execute each command in the script
file as if the user had typed it in.

In fact, you can still see the commands #comm, #reco, and #unre in
the word lists for some of the Infocom games--although if you try to
use them the program will probably fault :(

I implemented this feature in my pinfocom interpreter (v. 3.1, to be
out soon: it's not in 3.0), and I use it to test the interpreter by
creating complete or partial scripts for a bunch of games and
generating a transcript output, then testing each new version by
re-running the script and comparing to the old output. Works quite
well :)

Reply all
Reply to author
Forward
0 new messages