Everything about Inform that confuses me
Andrew C. Plotkin
only place it's really explained in the documentation is in chapter 6,
whhich gives the sequence for a Drop action. [GamePreRoutine, check
the three befores (player, room, object), do it, check the three
afters, GamePostRoutine, print "Dropped".] But --
First, that's not enough detail. It's unclear how befores and afters
check their arguments. (I gather *from an example* that there are
global variables called inp1 and inp2. But there are also things
called noun and second. Huh? What? How do these things work if the
arguments are in a funny order? They ain't in the index.)
Second, not all actions work that way. Some don't check afters (it
took me three days to understand why not -- sure it's obvious once you
understand it, but reading the documentation did not cause me to
understand it.) Some don't have direct objects, so (I assume) they
only check two befores and two afters, but it's not clear what that
means in terms of the arguments (assuming I understood the arguments
:-) Then there are actions like PutOn, which unleash a barrage of
Insert and Remove and LetGo and Receive actions, in, er, some order.
(Insert, Remove, LetGo, and Receive *are* in the index; each is
mentioned exactly once, on page 22, in a sentence which informs me
that the latter two are like the former two, but the other way
'round. Gurgle.)
Basically I feel like I need another (probably long) appendix, which
spells out in anal detail what all the standard actions really do.
Also how the standard properties behave. I found out last night (by
my usual method of getting it wrong at first) that setting the
describe routine of an object prevents the inital property from
working. I assume by this that the default describe routine is where
the initial/moved mechanism lives, so overriding it overrides that
mechanism, so you should provide it yourself in your describe routine.
Which is easy; but the point is that a lot of people must have gotten
that wrong at first.
Sigh. To paraphrase somebody, I know good documentation when I fail
to reread it twenty times. I've read the Inform Designer's Manual
about twenty times by now.
Note: Graham, if you take this personally I will walk over to England
and bop your head with a paper-towel roll.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Gareth Rees
> [difficulty in understanding how the library works]
I agree with your criticisms. What I do when I really want to know what
a verb does (whether it calls `after' routines; whether it calls them
before or after printing anything; whether the handler enforces the
`player must be carrying the object' rule or leaves it up to the parser)
is to read the VerbLib.h sources.
--
Gareth Rees
Mark Green
>Mostly, I'm confused about how the actions in the library work. The
>only place it's really explained in the documentation is in chapter 6,
>whhich gives the sequence for a Drop action. [GamePreRoutine, check
>the three befores (player, room, object), do it, check the three
>afters, GamePostRoutine, print "Dropped".] But --
>First, that's not enough detail. It's unclear how befores and afters
>check their arguments. (I gather *from an example* that there are
>global variables called inp1 and inp2. But there are also things
>called noun and second. Huh? What? How do these things work if the
>arguments are in a funny order? They ain't in the index.)
>Second, not all actions work that way. Some don't check afters (it
>took me three days to understand why not -- sure it's obvious once you
>understand it, but reading the documentation did not cause me to
>understand it.) Some don't have direct objects, so (I assume) they
>only check two befores and two afters, but it's not clear what that
>means in terms of the arguments (assuming I understood the arguments
>:-) Then there are actions like PutOn, which unleash a barrage of
>Insert and Remove and LetGo and Receive actions, in, er, some order.
>(Insert, Remove, LetGo, and Receive *are* in the index; each is
>mentioned exactly once, on page 22, in a sentence which informs me
>that the latter two are like the former two, but the other way
>'round. Gurgle.)
I agree absolutely. The Inform manual is excellent on design information and
examples, but doesn't give enough general rules for how things operate. It
took me *ages* to figure out how inp1, etc.. were calculated. It took me even
longer to realise that you could put a bit of code in for an exit and have it
return the location where you wanted the exit to lead - while you can't do
this with some other attributes.
Just like the original post, this isn't personal criticism. The inform
documentation is certainly a lot better than the documentation you get with the
downloaded version of TADS. <G>
--
Mark Green, CS Undergrad, Reading, UK -- Standard Disclaimers apply
"Dust! Dust! I *like* looking through Windows!"
Stephen Van Egmond
partially succeeds as a reference, but many parts of the specification
aren't very rigorous. In some respects, a reference manual should
constitute a complete, unambiguous specification of the subject.
In Inform's acase, any ambiguities can be resolved by reading the
libraries, but for some people (i.e. me) that is a frightening prospect.
I would be more than happy to contribute to the improvement of the
manual. I like the way Graham Nelson described it in the introduction:
"[some parts] are both leaden _and_ patronizing". The style of it is
excellent and just feels right for the subject.
Some manuals simply attempt to describe the syntax of the language,
whereas others try to describe what can be done, and hope that the syntax
shows through. It's like reading a book on C++ vs. a book on
object-oriented programming. I think the Designers' Manual does both
simultaneously and it doesn't always work.
I reiterate: I'm more than willing to help out in the manual's
development. If there were an IF game for learning programming, I'd have
5 out of 100 points, 100 being the skill for a finished game, giving me
the ranking of doe-eyed, frightened rookie.
/Steve
Tim Middleton
EE= to reread it twenty times. I've read the Inform Designer's Manual
EE= about twenty times by now.
I feel your pain! I empathise with the anguish. For me the inform manual was
like the carrot held forever just out of reach as I ran after it starving to
death! Finally I passed out with exhaustion and after sleeping many months
came back to it and am slowly putting things together.
As you said, the manual assumes a lot. While superficially appearing
structured to build concept upon concept, in fact virtually every chapter
incoperates concepts not yet introduced and therefore very confusing. many
things are not explained in very good detail.
I hate to complain. Because INFORM is a wonderful thing... and free!
But I when I read this I wanted to post my empathic wailings.
EE= bop your head with a paper-towel roll.
Hmmm, that's a good idea... bop myself on the head with a paper roll.
---
With love and squalor. <as...@torfree.net>
Tim Middleton
SE= parts] are both leaden _and_ patronizing". The style of it is
SE= excellent and just feels right for the subject.
Yes, I like Graham's style of prose writing as well. A friend of mine, who
shall remain nameless, finds it sounding a bit pretentious--but he's crazy.
<-:
I feel bad about my previous critical post about the manual. I still believe
in those criticisms (and a few more), but I still feel bad about it! I have
written shorter documentation for small programs and personally find manual
writing to be an absolutely excruciating exercise. That makes me feel even
worse for criticising some else's effort! Argh. I don't want to leave the
impression that i'm a complete crank who isn't eternally grateful!
On a completely different topic... although along the lines of learning
inform. Gareth Rees' "Through the Looking Glass" tutorial on his WWW page
is pretty good, except for a few confusing places; as far as it goes (one
room). Although one really has to know the basics of Inform before one can
probably begin to tackle it.
---
...with love and squalor. <as...@torfree.net>
Arlo Smith
: object-oriented programming. I think the Designers' Manual does both
It's too cute, grammatically strange, doesn't explain everything it
introduces, and doesn't explain the rest thoroughly enough. I think a
manual should be written to teach and not to show how clever the writer
is. Really! At the same time the language is fascinating and he did it,
and I got it for free. I feel very guilty complaining, but the pain is
great!! ;) So what else can I say? The manual has torn me to shreds! The
pattern: some explanation of a specific idea, the introduction of a
complicated example including many ideas, and an obscure quote with the
word 'door,' 'switch' or 'room' in it. I'm left biting my nails because I
know that other than the manual (a puzzle in itself), are some
example games, and a well-written tutorial. Hats-off to Gareth Rees....
Whatever.
Eventually it'll all sink in. My head is a dry sponge anyway.
Arlo Smith
: SE= I like the way Graham Nelson described it in the introduction: "[some
: SE= parts] are both leaden _and_ patronizing". The style of it is
: SE= excellent and just feels right for the subject.
: Yes, I like Graham's style of prose writing as well. A friend of mine, who
: shall remain nameless, finds it sounding a bit pretentious--but he's crazy.
: <-:
WHo's that? :) Yeah, well, if you run his manual through a grammar check,
--stand back--, because it'll blow up the program, monitor, HD, Ajax,
Pickering, and some other towns with lots of donut shops.
Torbj|rn Andersson
Reminds me of a post to rec.arts.books.tolkien some months back, where
someone had run part of The Silmarillion through a text analysis program,
and gotten the following result:
Reading age: 27
Overall legibility: Unreadable!
"This is not very good writing. It's difficult to read and the style
fault ratio is well above average. The author has little grasp of
clear writing."
(Sorry for getting this far off topic.)
Andrew C. Plotkin
> I would be more than happy to contribute to the improvement of the
> "[some parts] are both leaden _and_ patronizing". The style of it is
I just started writing (mostly as notes to myself) an "ANSI standard"
for the Inform language. It begins "This is entirely didactic. Mr.
Blobby has been shot." :-)
This is for the *language*, mind you. I'm not even going to touch the
libraries until I've done the language.
I'll bring in some excerpts tomorrow. It's kind of fun. (Fun to write,
I mean.)
BTW, I'm thinking in terms of writing additional documentation rather
than improving Graham's text. _The Inform Designer's Manual_ is a good
tutorial manual for writing games, I think; it's just a lousy
reference work. Besides, it's fun to read. How many manuals are fun to
read? Mine won't be.
russ...@wanda.pond.com
}: SE= parts] are both leaden _and_ patronizing". The style of it is
}: SE= excellent and just feels right for the subject.
}
}: Yes, I like Graham's style of prose writing as well. A friend of mine, who
}: shall remain nameless, finds it sounding a bit pretentious--but he's crazy.
}: <-:
}
}WHo's that? :) Yeah, well, if you run his manual through a grammar check,
}--stand back--, because it'll blow up the program, monitor, HD, Ajax,
}Pickering, and some other towns with lots of donut shops.
You need to run the U.K. English version :-)
Jon A. Preston
What is this newsgroup about? It sounds like I've unknowingly stumbled
upon a great thing here!
Let me explain:
I've recently picked up all my old Infocom games (Wishbringer first to be
exact), and I wanted to play them. Then I thought - hey - why not code up
some of these cool little things myself, but it seems that there is
already a language (Inform) that does most of the work for me! So I don't
have to start from scratch and create an Object class and then derive
everything from this! I've already got a lot! COOL!
So can someone please send me mail on how I can get a hold of this neat
little language (or class library) and get me going? Thanks!
jP
---------
ps - Does anyone want to answer some Infocom Wishbringer questions?
Please respond if so. Thanks in advance.
1) what good is saving the seahorse? (I know he'll save me from death
once, but anything else?)
2) is there any significance to the lighthouse?
3) am I supposed to get the cat from the tower? It doesn't have a white spot!
4) how can I get out of the tower without using "wish for freedom" or
"wish for darkness" to get past the hellhound?
THANKS!
--
----------------- Jon A. Preston (gt5...@acme.gatech.edu) -----------------
"If a man remains in me and I in him, he will bear much fruit." - John 15:5
Arlo Smith
: bl...@tofree.net (Arlo Smith) wrote:
: "This is not very good writing. It's difficult to read and the style
: fault ratio is well above average. The author has little grasp of
: clear writing."
Well, whether or not it's a grammatical masterpiece really doesn't matter.
Someone new to the language has trouble because some ideas are introduced
with advanced examples. I think if he introduced concepts using simple
examples and moved onto more complicated examples, it'd be fine. I'm
still reeling from the jump he makes in section 16. He introduces 'in
scope' then jumps to an advanced programming example which is pretty
unkind to a reader who is being introduced to these concepts for the
first time. Instead it'd be better to have a couple of simple examples
illustrating each concept. THEN an advanced one if he feels it's necessary.
My impression is that people have to skip parts, study the
games, and then come back. One guy said he read the manual 20 times, and
I believe him. Well, if I ever succeed in programming a decent game, I'll
go back and write an introduction to the language (though I'd need
permission to do that?!).