Dream Book Wanted: "Inform for Dummies"
Jay Goemmer
I was perusing the computer section of my local <shameless plug> Barnes and
Noble bookstore this afternoon, and I came across the volume "C for Dummies
(Vol. I)."
I've attempted to work through the "Ruins" example in the Inform Designer's
Manual, and I've also fiddled with the "Through the Looking-Glass" tutorial
(the latter requires that one be familiar with a computer programming
language, such as the aforementioned C).
This is neither to fault Graham Nelson nor Gareth Rees, but it seems that
there are several "holes" that I (as an admitted newbie) keep falling through,
since I'm *not* familiar with any actual computer programming language.
Would somebody *please* compile a volume entitled, "Inform for Dummies: A
Step-by-Step Guide for the (Hopelessly) Braindead," or something to that
effect?
Simply frustrated with my own lack of comprehension,
--Jay Goemmer
Brian J Parker
In article <66dffj$atp$1...@news01.micron.net>,
Jay Goemmer <radi...@not.my.address> wrote:
> Would somebody *please* compile a volume entitled, "Inform for Dummies: A
>Step-by-Step Guide for the (Hopelessly) Braindead," or something to that
>effect?
That would probably help some folks. I didn't have too much trouble with
learning Inform, but there's several times I was reading the manual and
said "Whoa, good thing I already know a bit about object-oriented
programming."
(To those who care: my two seperate attempts to write IF got derailed
about 1/3 of the way through due to lack of time.)
Don't get me wrong; I think that the manual, by itself, is a great
introduction to OO programming and isn't too hard to go through if you've
done a bit of coding. What would be nice, though, is a true "Dummies"
book; one that only taught a small subset of what Inform could do, but one
that would allow beginners to write simple works.
Of course, anyone reading this group who actually had free time would
probably be spending it writing *IF*, not writing a manual. =/
I *would* advise that you check out the listing (someone help me with the
URL) of would-be coders looking to get hooked up with "idea people," or
vice versa. I, for instance, listed myself as being interested in
co-authoring a small (IF contest sized) project in the fantasy or horror
genres; but I'm no good at writing plot or puzzles.
Cheers, sorry for digressing...
--
Wonder Boy
My biggest gripe with the manual right now is that it explains how
to do complex problems but I often find myself having problems figuring
out how to do simple stuff. As Graham implied, I'm sure he's at a
disadvantage trying to explain it completely in a manual, so I, for one,
would love to see someone try to take on the task.
-jon
"I come not to praise Caesar, but to bust a move." -mamster,
Adventurer's Lounge
"inky comes not to praise Caesar, but to neuter him" -typed by
inky, Adventurer's Lounge
(Text game fan? Check out http://fovea.retina.net:4001)
Jeff Johnson
Jay Goemmer wrote in message <66dffj$atp$1...@news01.micron.net>...
> I've attempted to work through the "Ruins" example in the Inform
Designer's
>Manual, and I've also fiddled with the "Through the Looking-Glass" tutorial
>(the latter requires that one be familiar with a computer programming
>language, such as the aforementioned C).
>
> This is neither to fault Graham Nelson nor Gareth Rees, but it seems
that
>there are several "holes" that I (as an admitted newbie) keep falling
through,
>since I'm *not* familiar with any actual computer programming language.
>
> Would somebody *please* compile a volume entitled, "Inform for Dummies:
A
>Step-by-Step Guide for the (Hopelessly) Braindead," or something to that
>effect?
Send me your real e-mail address (remove the NO-SPAM. from mine). I'm new
(not quite two weeks) at Inform, too, but I have quite a bit of programming
background. I'll send you some commented examples of my test files and maybe
that will help you pick up on what's going on.
Graham Nelson
In article <66kc3i$5...@usenet.srv.cis.pitt.edu>, Brian J Parker
<URL:mailto:bjp...@pitt.edu> wrote:
> In article <66dffj$atp$1...@news01.micron.net>,
> Jay Goemmer <radi...@not.my.address> wrote:
> >Step-by-Step Guide for the (Hopelessly) Braindead," or something to that
> >effect?
>
> learning Inform, but there's several times I was reading the manual and
> said "Whoa, good thing I already know a bit about object-oriented
> programming."
I should be more than happy to read and comment on any drafts, or to
offer occasional assistance -- I think it's an excellent idea.
But of course I am exactly the person who _shouldn't_ write it.
How about this, as an idea? You could try forming a small committee
of people and get each person to volunteer to write a short chapter on
some subject ("Chapter Three: If I'd Wanted The Door To Be Portable,
I'd Have Said So, For God's Sake"). Part of the fun, actually, would
just be deciding what the contents page should be...
The great advantage would be that you don't have to tell the
_whole_ truth, which is the curse of the Designer's Manual. As
Brian Parker put it:
> What would be nice, though, is a true "Dummies"
> book; one that only taught a small subset of what Inform could do, but one
> that would allow beginners to write simple works.
Just so!
What would people like, in such a text? Plenty of straight-forward
worked examples? (The DM has plenty of these, misleadingly called
"exercises", but they tend only to cover the weird and the difficult.)
A really heroic researcher might try looking over the last, oh,
12 months' worth of rec.arts.int-fiction to see what new Inform users
frequently ask or get wrong. It would be heroism, but then
rec.arts.int-fiction is a land of heros.
Or our putative researcher might try posting a questionnaire, along
the lines of "What do you wish you'd known then?" I do think market
research, so to speak, would be a big help.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Lelah Conrad
A Dummy Speaks:
>gra...@gnelson.demon.co.uk> wrote:
>
>What would people like, in such a text? Plenty of straight-forward
>worked examples?
YUP
> (The DM has plenty of these, misleadingly called
>"exercises", but they tend only to cover the weird and the difficult.)
YUP
>A really heroic researcher might try looking over the last, oh,
>12 months' worth of rec.arts.int-fiction to see what new Inform users
>frequently ask or get wrong. It would be heroism, but then
>rec.arts.int-fiction is a land of heros.
(Well, and a few Dummy adventurers, to increase the stature of genuine
heroes, gods and even big frogs ... )
Lelah
(currently blazing a path, torch in hand, through the TADS, Inform,
and ALAN manuals)
Jen Skripac
> I've attempted to work through the "Ruins" example in the Inform
Designer's
> Manual, and I've also fiddled with the "Through the Looking-Glass"
tutorial
> (the latter requires that one be familiar with a computer programming
> language, such as the aforementioned C).
I'll (whether it's appropriate or not =) ) use this as a jumping off point
for a
question I've been meaning to ask for a while now.
I sat down a while back and started reading the Inform Manual, got a bit
into it, decided it seemed enough like other programming I'd done to be
understandable, then read through the Inform Tutorial. All of the tutorial
made sense to me.
I started to step through the tutorial, creating the file along with it,
and at
the first compile point (right after the first room is created and
initialised)
tried the compile to see what happened. When I compile, I get a bunch
of errors that seem to be related to the libraries not being set up
properly.
When I compile the few early sample exercises in the manual, they go
through ok, and it's only when I start including libraries that I have a
problem.
Am I ahead of myself, or is it appropriate to try to work this out now,
before I've gotten very far in the official manual?
Jen. (skr...@mainstreams.com)
Mary K. Kuhner
In article <ant100137fc4M+4%@gnelson.demon.co.uk> Graham Nelson <gra...@gnelson.demon.co.uk> writes:
>Or our putative researcher might try posting a questionnaire, along
>the lines of "What do you wish you'd known then?" I do think market
>research, so to speak, would be a big help.
Conversations! I tried putting little copies of every object inside the
NPCs' heads (clunky); I tried using literals (but then you lose the synonym
power of the parser); it took me quite a while to hit on the use of
special scoping manuvers, and even now I'm leery of trying to explain
that. It did a lot of startling things on the way to working.
Also pockets, and in general there are a lot of trickinesses with
containers and supporters. "A Nasal Twinge" is not enough, since it
cravenly has a non-portable specimen; portable ones go wrong in far
more interesting ways.
I'd be willing to try to help with such a project, if someone else
wants to organize it.
Mary Kuhner mkku...@genetics.washington.edu
Andrew Plotkin
Jen Skripac (skr...@mainstreams.com) wrote:
> I sat down a while back and started reading the Inform Manual, got a bit
> into it, decided it seemed enough like other programming I'd done to be
> understandable, then read through the Inform Tutorial. All of the tutorial
> made sense to me.
> I started to step through the tutorial, creating the file along with it,
> and at
> the first compile point (right after the first room is created and
> initialised)
> tried the compile to see what happened. When I compile, I get a bunch
> of errors that seem to be related to the libraries not being set up
> properly.
What you should do is download a one-room sample game, with source code.
I'm sure Graham has a couple on his web page.
Compile that. Then you can start changing and adding things. Getting the
library arrangement right *is* hard, but once you get it right --
preferably by example -- you can stop worrying about it.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Kenneth Fair
In article <66mmn3$fga$1...@nntp5.u.washington.edu>,
mkku...@phylo.genetics.washington.edu (Mary K. Kuhner) wrote:
>Conversations! I tried putting little copies of every object inside the
>NPCs' heads (clunky); I tried using literals (but then you lose the synonym
>power of the parser); it took me quite a while to hit on the use of
>special scoping manuvers, and even now I'm leery of trying to explain
>that. It did a lot of startling things on the way to working.
Shudder. I'm trying to code up a general conversation routine that is
a bit more complicated than the "ask X about Y" syntax, and am banging my
head against the wall. The string manipulation tricks I know aren't
working well, and I have to delve more deeply into the parser at this
point. I'm leaving NPCs to the end, as much as possible, when I have
a better feel for the language and my project.
>Also pockets, and in general there are a lot of trickinesses with
>containers and supporters. "A Nasal Twinge" is not enough, since it
>cravenly has a non-portable specimen; portable ones go wrong in far
>more interesting ways.
Yes. Containers and supporters still give me problems, especially with
the details.
>I'd be willing to try to help with such a project, if someone else
>wants to organize it.
Ditto. My time is somewhat limited by my law school duties, but I could
be persuaded to do a chapter or two and work up some simple examples. I
fall, I think, in just the right range to be an author of this work. I
have some limited exposure to other languages and principles of OO, but
I have only slight practical programming experience. I have been through
the DM several times now, and I feel comfortable with all of the basics,
but I'm not so advanced that I've forgotten the things that gave me trouble.
One thing I would like to see, whether or not this happens, is a complete
list of all library routines and their calling syntax, as well as a list
of all of the global variables used by the library. Appendix 7 of the DM
is my idea, but it's not complete. I find myself unsure when to use
"action" or "action_to_be," for example, and I often have to make some
test code with lots of printing out just to see what's really going on.
A comprehensive variable list would help reduce the necessity of that, IMO.
--
KEN FAIR - U. Chicago Law | <http://student-www.uchicago.edu/users/kjfair>
Of Counsel, U. of Ediacara | Power Mac! | CABAL(tm) | I'm w/in McQ - R U?
"Any smoothly functioning technology will be
indistinguishable from a rigged demo." Isaac Asimov
David A. Cornelson
In article <ant100137fc4M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>
> In article <66kc3i$5...@usenet.srv.cis.pitt.edu>, Brian J Parker
> <URL:mailto:bjp...@pitt.edu> wrote:
> > In article <66dffj$atp$1...@news01.micron.net>,
> > Jay Goemmer <radi...@not.my.address> wrote:
> > > Would somebody *please* compile a volume entitled, "Inform for Dummies:"
After joining this little party in September, I have learned enough to
understand a few things. Graham is an object-oriented developer that
doesn't have a clue what the trees look like. He sees the forest and it
just can't be helped.
Next...after a short burst of energy trying to think up a reasonable
graphical interface to Inform, I gave up...for now. The reason? No
support from said author. I doubt he understands the need.
Once again the problem that many of us beginners have come across is that
we know how to code, but not necessarily in an oo language, and there is
no "help". The designer's manual is ridiculous. The important parts are
strewn from one end to the other and it never really answer's questions,
which is what a user's manual should accomplish.
My intention of a front-end was to create "wizards" so that if you wanted
to create a "location", you would click on the Location Wizard and
presto, a nice, neat little window would display all of the necessary
criteria, and most importantly, hide the syntax necessities from you, the
dummy.
This is sort of complicated by the fact that Inform's debug file is a
little too cumbersome. Given a list of objects, attributes, and
properties in a relatively simple form would go far to help me build a
front-end....but...
I digress...A manual is a much simpler idea and hearing that Graham would
support such an effort, gives me the inclination to say out loud and with
joy, I VOLUNTEER TO HELP!
I see the index of such a project as questions...
I. Definitions
a. What the heck is an Attribute?
b. What on earth is a Global?
c. Is this my Property or yours?
II. Structure of an Inform file
a. What does an Inform file look like when you begin coding?
b. Where do I put the title information?
c. Where do I put Global variables?
d. Where do I define Attributes?
e. Ditto Properites!
III. Mapping out your locations
a. How do I create a location
1. It's dark in here...turn on the light!
2. Where's that bathroom that I built?
b. There's an awful lot of scenery here but I can't find it!
1. Hey, how come I can pick up this four-poster iron bed?
....anyway...you get the picture...
Is this what you're talking about Jay?
David A. Cornelson, Chicago
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Lelah Conrad
On Wed, 10 Dec 1997 18:12:14 -0600, dcorn...@placet.com (David A.
Cornelson) wrote:
>
>I see the index of such a project as questions...
>
>I. Definitions
> a. What the heck is an Attribute?
> b. What on earth is a Global?
> c. Is this my Property or yours?
>
>II. Structure of an Inform file
> a. What does an Inform file look like when you begin coding?
> b. Where do I put the title information?
> c. Where do I put Global variables?
> d. Where do I define Attributes?
> e. Ditto Properites!
>
>III. Mapping out your locations
> a. How do I create a location
> 1. It's dark in here...turn on the light!
> 2. Where's that bathroom that I built?
> b. There's an awful lot of scenery here but I can't find it!
> 1. Hey, how come I can pick up this four-poster iron bed?
This is a great list of questions! I think we Dummies need an
inductive, not a deductive, process for learning IF languages. This
is especially true for those of us who are not programmers. Perhaps
these and other questions could somehow be linked up to the present
manual?
Lelah
Brian Beej Hall
In article <kjfair-1012...@ntcs-ip57.uchicago.edu>,
Kenneth Fair <kjf...@midway.uchicago.edu.REMOVEME> wrote:
>Shudder. I'm trying to code up a general conversation routine that is
>a bit more complicated than the "ask X about Y" syntax, and am banging my
>head against the wall.
Heh, this reminds me--I just played Hitchhikers again (for the first
time in quite a number of years) and was thinking about this problem.
Rememember this from the book:
Ford: Excuse me!
Prosser: Hello, yes? Has Mr. Dent come to his senses yet?
F: Can we assume for the moment that he hasn't?
P: Well?
F: Can we also assume that he'll be laying there all day?
P: And?
F: So your men will just be standing around here doing nothing.
P: Could be, could be...
F: Well, if you're resigned to doing that anyway, you might as well take
it as read that he's here and he and I could pop down to the pub for
a few minutes. Does that sound reasonable?
P: I suppose...
F: And if you'd like to drop by the pub later yourself, we could cover
for you in return.
P: Well, thank you...that's very kind!
F: So, if you'll just lie down here in front of the bulldozer.
P: What?
F: It's quite simple. My client, Mr. Dent, will only leave on the sole
condition that you take his place.
P: You want me to lie down over there?
F: Yes.
P: In front of the bulldozer?
F: Yes.
P: Instead of Mr. Dent?
F: Yes.
P: In the mud?
F: In, as you say, the mud.
P: In return for which, you will take Mr. Dent to the pub for a drink.
F: Yes.
P: Promise?
(Or something like that...)
Now, compare that to how you, as Ford, convince Mr. Prosser to lie down
in front of the bulldozer in the game:
> prosser, lie down
So, as you see, there is considerable conversation missing.
Of course, coding a parser to handle natural language conversation like
the Ford/Prosser exchange is, uh, "nontrivial". Very very cool, and
even more difficult. Let me know when it's done... ;-)
Cheers,
-Beej
Nir Levy
In rec.arts.int-fiction, dcorn...@placet.com (David A. Cornelson) saw fit to bestow on us:
[...]
>
>Once again the problem that many of us beginners have come across is that
>we know how to code, but not necessarily in an oo language, and there is
>no "help". The designer's manual is ridiculous. The important parts are
>strewn from one end to the other and it never really answer's questions,
>which is what a user's manual should accomplish.
One suggestion to all non-oo programmers that want to start doing OOP (
and this goes for every OOP, not just inform):
FORGET EVERYTHING YOU KNOW ABOUT HOW TO BUILD A PROGRAM!!!
and then, having your mind cleared of all the stuff they pump in you
in C/Pascal classes, and only then, will you be able to understand
OOP/D.
(And this have nothing to do with the fact that the Manual could be
better and I'm all for _Inform For Dummys_ book).
/NL
--
Nir Levy, The above opinions are my own,
nlevy @ usa.net not my employer's.
--
I didn't do it; Nobody saw me do it;
You can't prove anything; -Bart Simpson
--
Brian J Parker
In article <881798985...@dejanews.com>,
David A. Cornelson <dcorn...@placet.com> wrote:
>Next...after a short burst of energy trying to think up a reasonable
>graphical interface to Inform, I gave up...for now. The reason? No
>support from said author. I doubt he understands the need.
Twice now I've posted to r.a.i-f about doing a "Visual Inform"-- even if
it was just a text editor with syntax highlighting and a few code wizards,
it would go a great way to making Inform programming a little easier and
more automatic.
Both times I got a reply to the effect "I'm working on it, and no, I don't
need any help, but thanks." (I'm a Visual Basic programmer-- not very
sexy but hey, you can compile pretty fast code into DLLs now. And I've
taken at least an introductory course in compiler design, and actually
understood most of it...)
I'm not going to pretend I could tackle such a project myself but I can
help.
>Once again the problem that many of us beginners have come across is that
>we know how to code, but not necessarily in an oo language, and there is
>no "help".
A well-indexed .HLP file (yes, I'm largely a Windows Weenie) with plenty
of sample code would indeed be useful.
--
Richard G Clegg
Nir Levy (nl...@usa.net.TO_EMAIL_REMOVE_THIS) wrote:
: One suggestion to all non-oo programmers that want to start doing OOP (
: and this goes for every OOP, not just inform):
: FORGET EVERYTHING YOU KNOW ABOUT HOW TO BUILD A PROGRAM!!!
Hey, y'know, that's funny, because I often look at C++ code and think
"That person forgot everthing they knew about how to build a program"
so I guess your method actually works! :-)
Actually a programmer who likes to program that way will be writing
OO code in any language which allows it. My C code is pretty much OO
which is just the way it developed. Fortunately I was able to remember
everything I knew about how to build a program.
What I _loathe_ is the people who get carried away with OO and
start "A decimal digit is a class inheriting properties from the
binary digit class". Or spend the first 3 weeks of any project
rewriting their linked list class. Eventually colleagues get together
and hit the person's head off the wall repeatedly while shouting
"For fuxakes - can we have more emphasis on the programming and less
on the Object Oriented."
Of course that's just my opinion :-)
--
Richard G. Clegg Only the mind is waving
Dept. of Mathematics (Network Control group) Uni. of York.
email: ric...@manor.york.ac.uk
www: http://manor.york.ac.uk/top.html
Maynard Case
In article <ant100137fc4M+4%@gnelson.demon.co.uk>, Graham Nelson <gra...@gnelson.demon.co.uk> writes:
> In article <66kc3i$5...@usenet.srv.cis.pitt.edu>, Brian J Parker
> <URL:mailto:bjp...@pitt.edu> wrote:
> > In article <66dffj$atp$1...@news01.micron.net>,
> > Jay Goemmer <radi...@not.my.address> wrote:
> > >Step-by-Step Guide for the (Hopelessly) Braindead," or something to that
> > >effect?
> >
> > That would probably help some folks. I didn't have too much trouble with
> > learning Inform, but there's several times I was reading the manual and
> > said "Whoa, good thing I already know a bit about object-oriented
> > programming."
>
> I should be more than happy to read and comment on any drafts, or to
> offer occasional assistance -- I think it's an excellent idea.
> But of course I am exactly the person who _shouldn't_ write it.
>
> How about this, as an idea? You could try forming a small committee
> of people and get each person to volunteer to write a short chapter on
> some subject ("Chapter Three: If I'd Wanted The Door To Be Portable,
> I'd Have Said So, For God's Sake"). Part of the fun, actually, would
> just be deciding what the contents page should be...
I'd be interested in writing a chapter for this. Sadly it's been so long since I
started learning Inform that I've forgotten what I got stuck on...
If we get a whole team of people onto this, it might also be an idea to pass
chapters around so that any overly dull/technical/hard parts written accidentally
by the author of that chapter can be simplified by someone else.
Sounds like a fun project, though.
Maynard
(De-lurking just before he runs out of internet access for four weeks...)
--
m...@dcs.ed.ac.uk http://www.dcs.ed.ac.uk/~mc
3rd Year Computer Science Undergraduate, Edinburgh University
David A. Cornelson
In article <34919745...@news.ibm.net.il>,
nl...@usa.net.TO_EMAIL_REMOVE_THIS wrote:
>
> In rec.arts.int-fiction, dcorn...@placet.com (David A. Cornelson) saw fit
to bestow on us:
> [...]
> >
> >we know how to code, but not necessarily in an oo language, and there is
> >strewn from one end to the other and it never really answer's questions,
> >which is what a user's manual should accomplish.
>
> and this goes for every OOP, not just inform):
>
> FORGET EVERYTHING YOU KNOW ABOUT HOW TO BUILD A PROGRAM!!!
>
<...as Nir ducks his head because he MISSED THE POINT!!!>
Some background information is necessary for those of you that are OO
developers AND I-F writers. Forgive me if I shout....
Many of us that are involved in this genre began by sitting down in front
of a computer and PLAYING A GAME. Many of us like to write short stories
and poems and la-de-da, la-de-da, la-de-da, could give a rats ASS about
programming correctly in an OO language or not.
<quieter....taking a breath>
We simply want to transfer some of our creativity to another form.
Instead of writing another poem, (la-de-da), we would like to create a
world and share it with others.
With this motiviation understood, we have been in a long and fruitless
search for a tool or program that would take our creative ramblings and
help us "organize" them into an interactive fiction game.
Inform is probably as close as we're likely to get unless someone on YOUR
side of the table gets it. Look at it as a simpler version of Visual
Basic, which is not OO, but more OEA (Object-Event-Action). Then add some
forms to compensate for the syntax learning-curve and, wallah, you have a
tool that many "dummies" would greatly appreciate. I-F game writing would
likely increase ten-fold overnight.
<another deep breath>
Stop trying to turn poets into OO developers. If YOU'VE bridged the gap,
fine, but don't toss that medicine ball this way. We're just going to
duck....
Graham Nelson
In article <66ovf2$j...@usenet.srv.cis.pitt.edu>, Brian J Parker
<URL:mailto:bjp...@pitt.edu> wrote:
> In article <881798985...@dejanews.com>,
> David A. Cornelson <dcorn...@placet.com> wrote:
>
> >Next...after a short burst of energy trying to think up a reasonable
> >graphical interface to Inform, I gave up...for now. The reason? No
> >support from said author. I doubt he understands the need.
>
> Twice now I've posted to r.a.i-f about doing a "Visual Inform"-- even if
> it was just a text editor with syntax highlighting and a few code wizards,
> it would go a great way to making Inform programming a little easier and
> more automatic.
I do "understand the need", and indeed I have written such a text
editor, which does have syntax colouring and code wizards: you can
find it at
http://www.gnelson.demon.co.uk/zapinform/
but it only runs on an Acorn RISC OS computer, that being the sort of
computer I have. If I had a PC or a Macintosh, I might be able to
help others achieve the same results, but I haven't. As it is,
anyone who wants to see how e.g. the syntax colouring algorithm works
(which isn't obvious: Inform isn't an easy language to syntax colour)
is welcome to look at the source code, which is supplied with
ZapInform.
Seriously, how much more helpful could I be?
Alan Conroy
>After joining this little party in September, I have learned enough to
>understand a few things. Graham is an object-oriented developer that
>doesn't have a clue what the trees look like. He sees the forest and it
>just can't be helped.
Perhaps you know Graham better than I (I only "know" him from reading
his posts here). However, I can't help but think that you are being a
little hard on him. It is true that developers tend to see details
better than the big picture, but that is a bit of a stereotype. The
implication that an object-oriented programmer has a tendancy in this
direction is faulty. OOP is, partially, an attempt to abstract away
from details (away from the trees and to the forest). The actual
coding of classes and methods may be contrary to that, however (in my
experience).
>Next...after a short burst of energy trying to think up a reasonable
>graphical interface to Inform, I gave up...for now. The reason? No
>support from said author. I doubt he understands the need.
Again, is this a fair characterization, or are you making an
assumption? My authoring tool, Adventure Builder, has a Windows GUI
interface for those who want to use it (and DOS for those who don't).
But to be candid, the ONLY reason it does have a Windows GUI is
because I needed a project of sufficient scope to learn the Windows
3.1 API. If I did not have that need, Adventure Builder would not
have a GUI. First, I'm more of an engine guy than an interface guy.
Does that mean that I don't understand the importance of a nice
interface? Heavens no! I use nice GUIs all the time myself and
generally appreciate them. But its a matter of focus. Time is
limited and the work is unlimited, therefore I must prioritize. GUIs
may be important, but they are not ALL important. I suspect that
Graham is constrained by these same realities.
On the other hand, maybe you are right. Some of those who frequent
this newsgroup have often displayed antipathy toward anything not
text-only. Perhaps Graham is one of these. All I'm saying is give
the guy the benefit of the doubt.
>Once again the problem that many of us beginners have come across is that
>we know how to code, but not necessarily in an oo language, and there is
>no "help". The designer's manual is ridiculous. The important parts are
>strewn from one end to the other and it never really answer's questions,
>which is what a user's manual should accomplish.
Understanding this, I wrote Adventure Builder in a manner that did not
require OOP to implement a game. For the casual/uninitiated
programmer, OOP can be a can of worms. However, Adventure Builder
also suffers the consequences of not being OO. In other words, OOP
can cause its own set of problems, but it also solves many others.
No software can be all things to all people. Those that try
inevitably fail to please anyone. I think it must simply be accepted
that Inform is OO. If you really hate that, use something else or
write your own. I know how I'd react to someone who complained that
Adventure Builder did not support multiple-inheritance, virtual
methods, operator overloading, or whatever. My response would be: it
MIGHT support these in the future, but the system is oriented toward
weekend programmers - not professionals. If you want these features,
then it is not for you. With all the IF authoring tools out there,
certainly you could find something that fit your specific
needs/desires.
- Alan Conroy
From the firth, his bark was worse than his bight.
HarryH
In article <66dffj$atp$1...@news01.micron.net>, radi...@not.my.address says...
> Would somebody *please* compile a volume entitled, "Inform for Dummies:
A
>Step-by-Step Guide for the (Hopelessly) Braindead," or something to that
>effect?
Ohnoyoudon't.
Somebody was going to an Inform FAQ. Whatever happens to that?
I'd like to see an Inform FAQ created first. We can cover the dummy section
in "How to make a one room adventure", okay?
Here's a list of questions that I want answered in the Inform FAQ:
1. Easy disambiguation
2. Eliza (sample code)
3. Dealing with numbers. (53 of this, and 24 of that)
4. More sample codes.
Of course, I never had any real problem with Inform, except this stubborn
supporter problem. Does my years of programming experience and the fact that
I read all the manuals cover to cover multiple times before I sat in front of
the computer have anything to do with it?
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Brian Beej Hall
In article <Pz1k.2$104.1...@news1.atlantic.net>,
HarryH <har...@iu.net.idiotic.com.skip.idiotic.com> wrote:
>Somebody was going to an Inform FAQ. Whatever happens to that?
I'm way more up on that noise. (Ha! I've been wanting to use that
phrase all day.) My opinion is that a "dummies" book becomes worthless
after you read it, whereas a faq contains enough answers to remain
useful for a longer time and to a larger number of people.
Ever see the comp.lang.c faq? It rules. It is a book in itself, and is
very detailed. Probably 50% of the questions in the newsgroup are
covered in the faq.
A 1-2 punch of a good faq with a simple tutorial for beginners would
probably be a pretty damn fine thing, IMHO.
-Beej
Lovecraft
> Does my years of programming experience and the fact that
>I read all the manuals cover to cover multiple times before I sat in front of
>
>the computer have anything to do with it?
Probobly. It's hard to bridge the gap from art to programmer. I myself prefer
to start learning a language along the lines of "Let's print your name in the
middle of the screen!","Wasn't that fun?".
These simple seeming lessons actually give a person alot of firm foundation in
a programming language if they're not programming majors in college or
business. When I pick up a new language I basically try to make it do those
simple things that I first learned in basic. That gives me an insight into the
differences and similarities but also the ease or difficulty of the language.
I myself am having a bitch of a time learning Inform. For me the idea is the
interactive fiction, not the reading of a dry tome hundreds of pages in length.
That would come later, after I've actually satisfied my initial craving to
write IF.
Nick Nova
Patrick Kellum
In article <881893370....@dejanews.com>, David A. Cornelson was talking about:
>Many of us that are involved in this genre began by sitting down in front
>of a computer and PLAYING A GAME. Many of us like to write short stories
>and poems and la-de-da, la-de-da, la-de-da, could give a rats ASS about
>programming correctly in an OO language or not.
Then don't do the programming, team up together with someone who can
program and work together. There is an entire web page devoted to just
this subject, it contains an extreamly large list of programmers who are
waiting for good writters to work with (and writters looking for
programmers). Think of it as a computer dating service for I-F fans ;)
<URL:http://homepages.ihug.co.nz/~daleys/ifcollab.html>
For example, I can program just fine, but I couldn't write to save my life
(true, sad to say, that's why I port stuff) so if I wanted to write a game
people wanted to play I would go through the list and send out an email or
two to some writters.
Why struggle with something that will take a while to learn when you can
team up with someone who has already learned.
>We simply want to transfer some of our creativity to another form.
>Instead of writing another poem, (la-de-da), we would like to create a
>world and share it with others.
I belive Adventure Construction Set on the C64 was very easy to program
in, perhaps you could try that.
>With this motiviation understood, we have been in a long and fruitless
>search for a tool or program that would take our creative ramblings and
>help us "organize" them into an interactive fiction game.
Such a tool could be created easly without hacking up Inform and
destroying it for everyone who has takin the time to actually learn how to
use it (about 4 hours of reading/playing for the average person to learn
to create a simple game would be my guess).
>Inform is probably as close as we're likely to get unless someone on YOUR
>side of the table gets it. Look at it as a simpler version of Visual
>Basic, which is not OO, but more OEA (Object-Event-Action). Then add some
Visual BASIC is the wrong thing to base anything on, it's not even BASIC
anymore, more like a GUI construction set with a prmitive scriptiing
language stuck on it. I have nothing against BASIC, I even went to
colledge to study it, but Visual BASIC is a mistake.
>forms to compensate for the syntax learning-curve and, wallah, you have a
>tool that many "dummies" would greatly appreciate. I-F game writing would
>likely increase ten-fold overnight.
Yep, this happined when AGT was released. 'Nuff said.
>Stop trying to turn poets into OO developers. If YOU'VE bridged the gap,
>fine, but don't toss that medicine ball this way. We're just going to
>duck....
When you went in to get your drivers license, did they ask you to show
that you could drive first? If you couldn't drive, would you demand that
they give you your license anyway? I know that that is the Amerikan way
(sad, but true) but that doesn't not make it right. "I don't want to
learn, change the rules" is not a very mature answer.
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
Kenneth Fair
In article <Pz1k.2$104.1...@news1.atlantic.net>,
har...@iu.net.idiotic.com.skip.idiotic.com (HarryH) wrote:
>Here's a list of questions that I want answered in the Inform FAQ:
>1. Easy disambiguation
Disambiguation of what? For the most part, that's built right in.
>2. Eliza (sample code)
I'm *working* on this. I have the TADS code, but it's not quite a
straightforward port, especially if one is trying to include all of
the Inform speech syntaxes. Search and replace inside strings is also
tricky, since one can't really shove this stuff into the parse buffer
and Inform doesn't quite have the full string manipulation libraries
necessary to do it that way. The problem is soluble, though, and I
have it 1/3-1/2 licked. It may end up looking a bit nasty, but I'm
trying to make it as efficient and as extensible as possible.
>3. Dealing with numbers. (53 of this, and 24 of that)
That's actually built in to the library now. It may take a *bit* of
futzing with the "plural" property, but the parser can handle it.
>4. More sample codes.
David A. Cornelson
In article <881893370....@dejanews.com>,
dcorn...@placet.com (David A. Cornelson) wrote:
Okay, so I'm replying to myself...but I'm really hot about this topic...
I'm beginning to see a picture here. There are several issues.
1. How many I-F fans think I-F is about programming a game? a. How can I
write I-F using an object-oriented language in particular? 2. How many
I-F fans think I-F is about writing a story in an interactive form? a.
What tools will help me move my stories into an interactive form? 3. How
many think it's both? Note: For those that marshall the ability to use
both sides of their brains at the same time. 4. Unix rules! Using
complicated methods to solve seemingly simple problems is a joy and I
wish everyone could spend the next twenty years learning this stuff too!
Reply from novice: "Isn't that painful?" 5. The customer wishes a
simpler development tool or a better explanation for the current tool.
Reply from Unix guru: "Ah bugger the customer. If they can't learn OUR
way, I say bugger 'em!"
I get the impression that the OO supporters are very stubbornly against
any simplification of I-F development. They believe that something will
somehow be lost if a visual development tool is created. It's a fair
argument but one I answer all of the time when I'm asked whether C++ or
VB is appropriate. If you're writing a CPU intense system, use C++....if
however you're creating a simple user interface or report, you probably
should use VB or some other 3GL.
Writing reports in C++ is like hiring Graham to sort floppies. It's kind
of a waste.
Writing I-F in an OO form may be great for very complicated puzzles and
game layouts, but most of us would survive with a simpler tool.
1. I create an object (person, place, or thing) a. I define properties
of my object (name, description) b. Attibutes (light, enterable) 2. I
select an event for that object (push, pull, east, west, begin_turn) 3. I
write some relative code for this event and can refer to other objects
and events within my code box for this object_event.
Granted, this would make MY life easier, but on top of this we would have
to add some syntax checking AND/OR forms to accept specific imputs to
different types of actions for non-coding dummies.
I am not proposing to change Inform. It's a pretty nice thing as it
stands. I probably don't need a front-end anymore because I can force my
little top down brain to subvert the OO of Inform to do my bidding as I
please.
I am proposing that we create some vehicle by which newcomer's and
non-coders don't get frazzled at the first sight of the designer's manual
and never come back. Whether that's a new manual, with simpler
instructions and examples, or some sort of front-end to Inform, I really
can't say.
We want others to share their creativity, not their license to program.
If I'm wrong about this, well, then I guess maybe the beginners of this
news group should start a new one called rec.arts.int-fiction.writers
OR rename this news group to rec.arts.int-fiction.oop....
Jeff Johnson
A
>Step-by-Step Guide for the (Hopelessly) Braindead," or something to that
>effect?
I've taken the challenge. I'm a newbie myself, but I think I'm getting the
hang of things quickly. I'm going to post my guide on my web site and invite
any and all comments. I should have something up by (late) Friday night.
I'll drop another message here when it's ready.
Of course, it's not going to be COMPLETE! It will be a work in progress, and
I invite anyone to contribute. Remove the NO-SPAM. from my address if you
wish to e-mail me directly.
Magnus Olsson
I'm not going to quote David Conelson's posts here, since his points
are spread out over quite a few posts. I hope people won't be too
unhappy with me for that.
Anyway, David, your basic request - an easy way of making IF without
having to bother with programming, object orientation, Inform syntax,
and so on - is very reasonable. You're certainly not alone in wanting
something like that.
The problem is just that it's very difficult to make such tools. In
fact, the "IF for non-programmers" system is sort of the Holy Grail of
IF - sought after by many, found by none. If I knew how to do it, I'd
probably create it. For even I (who earn most of my money doing OO
programming these days) find the progpramming to be ahssle, soemthing
that gets between my ideas and their realization. I'm sure *everybody*
who's ever tried to write IF recognizes the feeling.
Where you're *not* being reasonable is in publicly defaming Graham
Nelson and everybody else because they don't give you what you want.
Try to understand that the reason people don't provide you with these
tools is that doing so is very difficult and takes a long
time. Unpayed time, at that - nobody can make money writing IF tools
nowadays.
There is no conspiracy of elitist OO programmers who are denying you
your tools because they don't feel you - as a non-programmer - are
worthy of it.
Nobody owes you anything. In particular, Graham Nelson, whom you're so
fond of attacking, has already spent a few years of his life
developing Inform and giving away all his efforts to you - and
everybody else - for free. Yet you seem to take it as a personal
insult that you can't understand his works and keep posting nasty
attacks on his personality because he doesn't immediately donate
another man-year of effort in improving his works.
Mr. Cornelson, you're behaving like a spoilt child.
Richard G Clegg
David A. Cornelson (dcorn...@placet.com) wrote:
: Stop trying to turn poets into OO developers. If YOU'VE bridged the gap,
: fine, but don't toss that medicine ball this way. We're just going to
: duck....
The thing is that programming IF is a relatively complex programming
task. It's all very well saying that you don't want to become a
programmer but how much respect would you have for someone who said
"I want to be a poet, but this learning the alphabet seems a lot of
effort". I-F is a form of natural language processing (persuading
computers to "make some sense" of human language) and that is a
very very difficult bit of computing. There are tools that can make
it easier but they can only come so far. There's got to be a point
where you roll up your sleeves and say "I am both a poet and an OO
developer" because there is currently no way to make a system which is
both powerful enough to create fairly general games and simple enough
to be completely intuitive. This is not to say that Inform is the
perfect solution to the problem but, speaking as someone who's learned a
lot of computer stuff from a lot of manuals, the Inform language and the
manual that go with it really aren't so bad. What you don't seem to
understand is that they're an approach to a problem which is naturally
very difficult indeed.
I'm sure that if enough people got together and really worked on it
they could produce a better and more comprehensible Inform manual but
it still wouldn't make writing IF a magically easy task.
Patrick Kellum
In article <66qgfk$mko$1...@neko.syix.com>, Patrick Kellum was talking about:
Ugh, I always get these names confused!
>I belive Adventure Construction Set on the C64 was very easy to program
That should, of course, be AdventureWriter (A.K.A. Quill outside the USA).
Allen Garvin
>
>I. Definitions
> a. What the heck is an Attribute?
> b. What on earth is a Global?
> c. Is this my Property or yours?
>
>II. Structure of an Inform file
> a. What does an Inform file look like when you begin coding?
> b. Where do I put the title information?
> c. Where do I put Global variables?
> d. Where do I define Attributes?
> e. Ditto Properites!
>
>III. Mapping out your locations
> a. How do I create a location
> 1. It's dark in here...turn on the light!
> 2. Where's that bathroom that I built?
> b. There's an awful lot of scenery here but I can't find it!
> 1. Hey, how come I can pick up this four-poster iron bed?
The Designer's Manual answers all these questions! You can find where the
answer is to almost every one of these by glancing through the table of
contents. It's easy to read, well-organized, literate and often humorous. It
might be the best tutorial/manual for a language I've ever seen (and most that
I've read are abysmal).
I can't see how it can easily be improved upon.
--
Allen Garvin kisses are a better fate
--------------------------------------------- than wisdom
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil e e cummings
Andrew Plotkin
Lovecraft (love...@aol.com) wrote:
> I myself am having a bitch of a time learning Inform. For me the idea is the
> interactive fiction, not the reading of a dry tome hundreds of pages in
> length.
To pick a not-insignificant nit, I find the Designer's Manual to be a
lively, amusing tome hundreds of pages in length.
An IF system (the Inform language-plus-library), unlike a bare language,
is a very complicated thing when you *start* working with it. When you say
"the idea is the IF," and you want to start with the IF, you are
implicitly requiring hundreds of pages of knowledge. You can osmose that
in a lump or work up to it slowly, but it's waiting for you.
It's probably best to start with a very tiny goal. Make a room. Make a
button. Make the button go "ping" when you push it. That's not IF, but
it's a start, and it's exactly what's in the first two chapters of the
DM's Book Two (the book on "Designing."[*])
I'm not saying the DM is *the* way to start learning Inform. I think a
"for dummies" or FAQ is great.
I do think, however, that just about every FAQ entry is going to end
"...see section X of the Designer's Manual."
I'm not going to volunteer to help with a FAQ, because I regard the DM as
the ideal way (for me) to learn a system, and if I were writing a book on
Inform I'd produce something very much like it. Which would be redundant.
[* You may want to start reading with "Designing", and skip Book One,
"Programming". That gets right into writing pieces of a sample game. On
the other hand, you may find yourself skipping back to look up bits of
programming syntax in Book One. Is this a surprise?]
Stephen Granade
On Thu, 11 Dec 1997, David A. Cornelson wrote:
> Many of us that are involved in this genre began by sitting down in front
> of a computer and PLAYING A GAME. Many of us like to write short stories
> and poems and la-de-da, la-de-da, la-de-da, could give a rats ASS about
> programming correctly in an OO language or not.
>
> <quieter....taking a breath>
>
> We simply want to transfer some of our creativity to another form.
> Instead of writing another poem, (la-de-da), we would like to create a
> world and share it with others.
And I would like to take the melodies and counterpoints that I hear in my
head and turn them into songs. But until I sit down and learn composition
and how writing music works, it ain't gonna happen.
In _any_ artistic endeavor there is a certain amount of technique which
must be learned. With IF, there happens to be the double whammy of needing
to know how to write and needing to know how to program.
The short term answer for what you are complaining about is to take the
TV/movie/play approach: team up. Find a programmer and work with him/her.
Look at the IF collaborator's list
(http://homepages.ihug.co.nz/~saleys/ifcollab.html) and pick a partner.
The long term answer? I honestly don't know. I'd love to have a machine
which would take my ideas and turn them into <insert choice of art here>.
Until that happens, we're stuck with having to develop our ideas using
imperfect tools.
> Inform is probably as close as we're likely to get unless someone on YOUR
> side of the table gets it.
Gets what? Even the "Visual Inform" which you describe wouldn't alleviate
the problem you describe; it would merely hide it under the rug. Sure, it
would be nice to have such a system to make the cut-and-paste work (i.e.
copy a previously-written room, change things here, cut things there) more
visually appealing, but it wouldn't help with the nasty coding which
occurs any time you want to do something non-trivial. And if you want to
avoid that, why not use a system like AGT which is designed for such?
There's no cabal of programmers giggling maniacally at their successful
attempts to keep artists away from IF. You're dealing with people who are
_freely_ devoting their time to make tools for you. "Visual Inform" would
be a non-trivial task--think of the number of employees Borland or
Microsoft or Metrowerks have writing their nice compilers. _And_ we would
want this done for free. _And_ we would want it ported to God only
knows how many machines, given our propensity for wanting IF tools to run
everywhere.
I'm not trying to belittle your complaints, honest. You've raised valid,
important issues. I'm trying to point out why a) such tools haven't been
written, b) why they're not likely to be written any time soon, and c) why
screaming at those who give of their time freely to write IF tools is a
non-optimal way to get what you want.
> Stop trying to turn poets into OO developers. If YOU'VE bridged the gap,
> fine, but don't toss that medicine ball this way. We're just going to
> duck....
Nobody's trying to turn poets into programmers other than the poets
themselves. Sorry to be harsh, but if you don't want to learn the
techniques, don't shout at those who do.
Stephen
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Check out
Duke University, Physics Dept | http://interactfiction.miningco.com
Andrew Plotkin
David A. Cornelson (dcorn...@placet.com) wrote:
> 1. How many I-F fans think I-F is about programming a game?
I'm very much afraid that the significant question is "How many IF
*authors* -- those that have completed a game -- think that IF is about
programming a game?"
> Writing I-F in an OO form may be great for very complicated puzzles and
> game layouts, but most of us would survive with a simpler tool.
I know what goes into even a simple game layout. The part that can be
handled with a simpler tool *is not the hard part*. Nor is it the
time-consuming part. Nor is it the part which took the majority of my
learning time.
Now, I know that a simpler tool would be a waste of my time. How dare I
say it would be a waste of yours? Obviously I can't say that.
I can only express my professional estimate, which is that someone who
uses Inform with a non-programming interface will either (A) go beyond it
within a few days, and give it up, or (B) spend unbounded time and effort
trying to force his ideas to fit within a tool not strong enough for them.
L. Ross Raszewski
In article <e7vDG2r...@ntawwabp.compuserve.com>,
"Jeff Johnson" <pawp...@NO-SPAM.geocities.com> wrote:
> I've taken the challenge. I'm a newbie myself, but I think I'm getting the
> hang of things quickly. I'm going to post my guide on my web site and invite
> any and all comments. I should have something up by (late) Friday night.
> I'll drop another message here when it's ready.
> Of course, it's not going to be COMPLETE! It will be a work in progress, and
> I invite anyone to contribute. Remove the NO-SPAM. from my address if you
> wish to e-mail me directly.
Okay, I'm going to make a completely egocentric request. Every time I
see anyone mention menus in relation to... well anything... The first and
last word always seems to be "use Graham Nelson's menus.h replacement"
Without a single word as to the fact that Graham's replacement _isn't_
the only one available (I can think of at least _one_ other system,
equally easy to use and slightly more versatile, hint, hint)
Thanks
Lovecraft
>The Designer's Manual answers all these questions! You can find where the
>answer is to almost every one of these by glancing through the table of
>contents. It's easy to read, well-organized, literate and often humorous. It
>
>might be the best tutorial/manual for a language I've ever seen (and most
>that
>I've read are abysmal).
>
>I can't see how it can easily be improved upon.
I don't think anyone is saying that. I think that beginners are just asking for
a "beginner's tutorial" that goes a little farther than the "Ruins" or "Alice"
examples.
Here's an analogy: I take Anatomy and Physiology in college. The Professor
tells us the name of the text we need. It's huge. Hundreds of pages.
1. The Professor tells us to read the whole book and then he'll give us a test.
or
2. He takes us chapter by chapter, explaining the concepts and answering
questions.
Method 2 is the standard concept of education. Yes, some people can do it on
their own, but if everyone could what is school for?
I still have my Anatomy book and refer to it when I need info on something, but
I know that I wouldn't have made head nor tail of it without my Professor.
Nick Nova
Graham Nelson
In article <66ovls$ses$4...@pump1.york.ac.uk>, Richard G Clegg
<URL:mailto:rg...@york.ac.uk> wrote:
>
> What I _loathe_ is the people who get carried away with OO and
> start "A decimal digit is a class inheriting properties from the
> binary digit class". Or spend the first 3 weeks of any project
> rewriting their linked list class. Eventually colleagues get together
> and hit the person's head off the wall repeatedly while shouting
> "For fuxakes - can we have more emphasis on the programming and less
> on the Object Oriented."
Steady on... I used to program in Smalltalk, you know. I used to
send little messages to the Platonic concept of the number "3" to
ask it to add "5" to itself, letting me know which instance of the
class Integer would arise as a result. It helped make me the well-
adjusted person I am today.
Just to dredge a serious point out of this, though, IF is naturally
OO: the fundamental assumptions of the text adventure's model world
are centred on name-able, usually indivisible objects. This I
suspect arises from the ontological natural of language -- that is,
the tendency for English to be object-oriented because of its use
of specific nouns.
That being so, it's reasonable to program IF in an OO way.
Graham Nelson
In article <66r9qq$5un$1...@bartlet.df.lth.se>, Magnus Olsson
<URL:mailto:m...@bartlet.df.lth.se> wrote:
>
> The problem is just that it's very difficult to make such tools. In
> fact, the "IF for non-programmers" system is sort of the Holy Grail of
> IF - sought after by many, found by none.
I might say that, like Andrew elsewhere in this thread, I just don't
believe in this particular Grail. The range of behaviour needed by
puzzles and activities in a game of any artistic worth exceeds
the range of behaviour which can be generated by a non-programming
system.
(This is to say nothing about Inform's ease of use, or lack of it,
_qua_ programming tool.)
I believe that a game, in order to have some artistic worth or
indeed playability, has to satisfy a form of Turing Test. (It's an
old story, but for those who haven't heard it: Turing proposed that
a satisfactory definition of "an intelligent program" would be one
that seemed to be intelligent. If you could talk to it via a
teletype without realising that it wasn't a human being, then it
would pass. No program has yet passed this test, except under very
unnatural constraints.)
I suggest that the analogous test is this. The game has to be
plausibly a simulation of a world in which many actions are
possible. The game will fail this test if it seems only a row
of locations, with elementary connections between, and one or
two passive objects in them. The game will pass if it seems as
rich with possibility as, say, the Zork I underground.
My point is just that a non-programming tool can only make the
first kind of "game", or else copies of what is essentially a
single original game. The Scott Adams / Brian Howarth games,
for instance, are basically duplicates of "Adventureland", with
the essential puzzles -- light and the lamp, treasure collection --
programmed into the "hardware" of the format. And yet even they
contain a substantial amount of quite cunning code, and I don't
think they could be assembled without programming. For example,
suppose you drop the bees in "Adventureland":
85) 18 23 [DRO BEE]
? HAS (26 = bees in a bottle)
? IS_in_AR (27 = large sleeping dragon)
-> 53 = MOVE_INTO_AR (24 = large african bees)
-> 53 = MOVE_INTO_AR (44 = *DRAGON EGGS* (very rare))
-> 55 = REMOVE (27 = large sleeping dragon)
-> 43 = PRINT(The bees attack the dragon ....
(I won't reveal what happens in this contingency.) Even these
minor complexities would stretch the abilities of a purely
mechanical adventure-creator.
Lucian Paul Smith
OK, here are some of my thoughts on the thread, and some suggestions.
First off, it *is* possible to create a work of IF without knowing
anything about programming. As someone else mentioned, go to
http://homepages.ihug.co.nz/~daleys/ifcollab.html
This is a serious suggestion.
Secondly, I think that compiling a list of common problems and solutions
is an excellent idea, and one that should be followed up on immediately.
As I said last time, and which no-one took me up on [*sniff*], go to:
http://c2.com/cgi/wiki?IntFicInformTips
and add your questions and answers directly to the page by clicking on the
'EditText' link at the bottom of the page.
<shameless plug>
And hey, while you're there, you can check out &/or add to the IF Patterns
Pages! What a bonus!
</shameless plug>
-Lucian "Lucian" Smith
Kenneth Fair
In article <ant112317d07M+4%@gnelson.demon.co.uk>, Graham Nelson
<gra...@gnelson.demon.co.uk> wrote:
>In article <66ovf2$j...@usenet.srv.cis.pitt.edu>, Brian J Parker
><URL:mailto:bjp...@pitt.edu> wrote:
>> In article <881798985...@dejanews.com>,
>> David A. Cornelson <dcorn...@placet.com> wrote:
>>
>> >Next...after a short burst of energy trying to think up a reasonable
>> >graphical interface to Inform, I gave up...for now. The reason? No
>> >support from said author. I doubt he understands the need.
>>
>> Twice now I've posted to r.a.i-f about doing a "Visual Inform"-- even if
>> it was just a text editor with syntax highlighting and a few code wizards,
>> it would go a great way to making Inform programming a little easier and
>> more automatic.
>
>I do "understand the need", and indeed I have written such a text
>editor, which does have syntax colouring and code wizards: you can
>find it at
>
> http://www.gnelson.demon.co.uk/zapinform/
>
>but it only runs on an Acorn RISC OS computer, that being the sort of
>computer I have. If I had a PC or a Macintosh, I might be able to
>help others achieve the same results, but I haven't. As it is,
>anyone who wants to see how e.g. the syntax colouring algorithm works
>(which isn't obvious: Inform isn't an easy language to syntax colour)
>is welcome to look at the source code, which is supplied with
>ZapInform.
>
>Seriously, how much more helpful could I be?
Yes, let's please not bash Mr. Nelson. He's obviously spent far more time
working on Inform than anyone with a real life should have, for no financial
reward whatsoever. Remember that Inform has essentially been a one-man
project up to this point.
With respect to syntax coloring on the Mac: I use BBEdit to program Inform,
as I suspect a number of other Mac Informers do. BBEdit already has
built-in syntax coloring for C/C++, Pascal, and HTML. Perhaps if you
gave them your algorithm they could include Inform syntax coloring?
Bare Bones Software is at <http://www.barebones.com/>.
Andrew Plotkin
Kenneth Fair (kjf...@midway.uchicago.edu.REMOVEME) wrote:
> With respect to syntax coloring on the Mac: I use BBEdit to program Inform,
> as I suspect a number of other Mac Informers do. BBEdit already has
> built-in syntax coloring for C/C++, Pascal, and HTML. Perhaps if you
> gave them your algorithm they could include Inform syntax coloring?
> Bare Bones Software is at <http://www.barebones.com/>.
The Metrowerks source editor also does syntax coloring, in multiple
languages. Does anyone know if the coloring algorithm can be customized?
(Is ther a resource or template buried somewhere that we can play with?)
(I use BBEdit Lite, which doesn't have the syntax-coloring feature of
BBEdit.)
Andrew Plotkin
Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
> I believe that a game, in order to have some artistic worth or
> indeed playability, has to satisfy a form of Turing Test.
> I suggest that the analogous test is this. The game has to be
> plausibly a simulation of a world in which many actions are
> possible. The game will fail this test if it seems only a row
> of locations, with elementary connections between, and one or
> two passive objects in them. The game will pass if it seems as
> rich with possibility as, say, the Zork I underground.
I don't even think you have to get that abstract. It's all the fiddly
little details which require programming.
I mean, you make a stone cube and give it a description: "You are
surprised to find that it's covered with hieroglyphs." And then you think,
well, it's dumb to be surprised every time you look at it; the player
should only be surprised the *first* time. This is the kind of detail
which is, frankly, taken for granted nowadays. AGT writers may not have
taken it for granted, but we do.
And this kind of logic is very easy to express in an imperative language
such as C or Inform or even Basic. It looks like
if (self.flag == 0) {
self.flag = 1;
print "You are surprised to find that it's covered with hieroglyphs.^";
}
else {
print "It's covered with hieroglyphs.^";
}
If you know anything about programming, this is as easy as breathing --
bar matters of syntax, which can be annoying but are rarely fatal. If you
*don't* know anything about programming, no tool can help you create
this. The best that can be automated is a point-and-click interface to
build an "if" statement out of component parts. Which is just miserable.
Now the original poster was complaining about "object-oriented"
programming in particular, but I think that's a detail. Inform game
programming uses a set of abstractions to define the world and its
objects. That by itself makes it "object-oriented", and it has been since
Inform 5 at least -- the extra pieces of OO syntax added in Inform 6
aren't really used by the library at all.
Jeff Hatch
Andrew Plotkin wrote:
[snip]
> I know what goes into even a simple game layout. The part that can be
> handled with a simpler tool *is not the hard part*. Nor is it the
> time-consuming part. Nor is it the part which took the majority of my
> learning time.
>
> Now, I know that a simpler tool would be a waste of my time. How dare I
> say it would be a waste of yours? Obviously I can't say that.
>
> I can only express my professional estimate, which is that someone who
> uses Inform with a non-programming interface will either (A) go beyond it
> within a few days, and give it up, or (B) spend unbounded time and effort
> trying to force his ideas to fit within a tool not strong enough for them.
"A visual tool" doesn't necessarily denote a "non-programming
interface." Witness Microsoft Visual C++, which did not remove one
ounce of functionality from Microsoft C++ 7.0, but added an "AppWizard"
let developers create a Windows program interfaces without hassling with
the core programming details. Similarly, a "Visual Inform" with a handy
little "Room Wizard" would still be able to define complex rooms--but
would do the simple ones much more quickly.
Just because complex game ideas can't be handled quickly and neatly with
cute visual tools doesn't mean that the cute visual tools can't save
time on the petty stuff. If you "go beyond it within a few days" that's
no reason to give it up. (Actually, my greatest peeve with TADS is that
it's far LESS reprogrammable than my system, since parsing is built-in!
And my system definitely does not have a standard programmer's
interface.)
Hopefully my system will prove that "visual tools" can create good
games.
I would also argue that expanding the standard library to include some
common situations would make it possible for imaginative people with
fairly low programming skill to write good games. Those of us who are
programmers will naturally want to customize certain classes--but why
shouldn't the library have default pockets, desks with drawers, etc.,
which are adequate for imaginative non-programmers?
AGT's library sucked, not just the system. :-)
-Rúmil
Jeff Hatch
Andrew Plotkin wrote:
[snip]
You can't take programming out of game creation, or at least not
easily. But let's face it: Graham Nelson and others have already taken
most of the work out! The sophisticated code-handling needed to parse a
command is far more difficult to code properly than, hieroglyphs on a
cube.
The same arguments that have been advanced against a "Visual Inform"
could be advanced against the creation of Inform in the first place:
You're going to have to program anyway, so why not write your game from
the ground up in C?
Because it's easier if the part of the game which almost *all*
adventures have in common doesn't have to be re-written over and over
again. Similarly, it wouldn't be hard to create a class of item which
displays a different description the first time you see it, and only the
first time. That may be an odd example--but there are more complex
things that we don't put in libraries, which really should be there.
For instance, in the "desk with drawer" thread, I was surprised to find
several people who said they don't *want* pre-coded objects like this
one, and that if they write games they're going to make their own desks
from scratch. That's fine for them, and that's probably what I'd do
(given my perfectionist tendency to reinvent the wheel), but why not put
the pre-coded desk in the standard libraries for the non-programmer
writers?
-Rúmil
Joe Mason
In article <66ovls$ses$4...@pump1.york.ac.uk>,
Richard G Clegg <ric...@manor.york.ac.uk> wrote:
>binary digit class". Or spend the first 3 weeks of any project
>rewriting their linked list class. Eventually colleagues get together
Ironic, since the whole POINT of OO is to be able to write one linked list
class that works and never have to rewrite it again...
Joe
David J Wildstrom
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>The Metrowerks source editor also does syntax coloring, in multiple
>languages. Does anyone know if the coloring algorithm can be customized?
>(Is ther a resource or template buried somewhere that we can play with?)
I use Alpha, a shareware emacsish thing. If anyone knows how to do TCL "modes",
they could code an inform synax colorer for Alpha pretty easily. I tried
fiddling with the included file cMode.tcl, but I could never get it to work
right. Anyone who has lots of spare time and does inform coding on the Mac
might want to hop on over to InfoMac and get Alpha (it's about 4M in .hqx)...
maybe they have a clue how this TCL thing works and can roll out a mode for the
rest of us.
+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into |
| theorems. -Paul Erdos |
+-------------------------------------------------------------+
| David Wildstrom |
+-------------------------------------------------------------+
Andrew Plotkin
> > 1. How many I-F fans think I-F is about programming a game?
> I'm very much afraid that the significant question is "How many IF
> *authors* -- those that have completed a game -- think that IF is about
> programming a game?"
The immediate comeback, I'll quickly anticipate, is "Well, what if the
available tools are preventing everyone from finishing games *except*
programmers?"
The comeback to *that* -- already mentioned -- is "Look at what was done
with earlier, simpler systems like AGT."
This is not a complete answer, since there's a matter of audience
expectation. We now expect pretty complex behavior in all sorts of
details, and arguably this was not true of the IF community before
Unnkulia and Curses appeared. But I'd argue this increase in standards
was only possible with the full-programming-language-plus-library
approach of TADS and Inform.
Kenneth Fair
In article <erkyrathE...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) wrote:
>Kenneth Fair (kjf...@midway.uchicago.edu.REMOVEME) wrote:
>
>> With respect to syntax coloring on the Mac: I use BBEdit to program Inform,
>> as I suspect a number of other Mac Informers do. BBEdit already has
>> built-in syntax coloring for C/C++, Pascal, and HTML. Perhaps if you
>> gave them your algorithm they could include Inform syntax coloring?
>> Bare Bones Software is at <http://www.barebones.com/>.
>
>The Metrowerks source editor also does syntax coloring, in multiple
>languages. Does anyone know if the coloring algorithm can be customized?
>(Is ther a resource or template buried somewhere that we can play with?)
>
>(I use BBEdit Lite, which doesn't have the syntax-coloring feature of
>BBEdit.)
And unfortunately, the BBEdit syntax coloring is one of the few parts of
the program that cannot be scripted or extended with a BBEdit extension.
(I thought of doing it myself, then read the manual which had a big "You
can't do this, so don't even try" in it.)
Kenneth Fair
In article <66nvq6$73h$1...@hubble.csuchico.edu>, be...@ecst.csuchico.edu
(Brian "Beej" Hall) wrote:
>In article <kjfair-1012...@ntcs-ip57.uchicago.edu>,
>Kenneth Fair <kjf...@midway.uchicago.edu.REMOVEME> wrote:
>>Shudder. I'm trying to code up a general conversation routine that is
>>a bit more complicated than the "ask X about Y" syntax, and am banging my
>>head against the wall.
[snip amusing HHGTTG dialogue]
>Of course, coding a parser to handle natural language conversation like
>the Ford/Prosser exchange is, uh, "nontrivial". Very very cool, and
>even more difficult. Let me know when it's done... ;-)
Oh, good God, no. I'm not even going to get close to a full NL processor.
I'm just trying to do Eliza. (Which is actually appropriate, since I'm
coding a psychiatrist.)
dcorn...@placet.com
In article <ant1218320b0M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>
> Just to dredge a serious point out of this, though, IF is naturally
> OO: the fundamental assumptions of the text adventure's model world
> are centred on name-able, usually indivisible objects. This I
> suspect arises from the ontological natural of language -- that is,
> the tendency for English to be object-oriented because of its use
> of specific nouns.
>
> That being so, it's reasonable to program IF in an OO way.
>
Okay, I'm done ranting...I hope no one is mad but I went back through the
archives and discovered that this conversation happened this past January
as well.
I liked this conversation a great deal and learned about where everyone
stands and I'm beginning to be swayed. I think the reason I got hot was
because everyone was either ignoring the issue or sort of summarily
dismissing it.
My shouting caused everyone to state a fairly lengthy opinion about
various subjects and I believe that is what was needed. I'm sorry some of
you have been down this road before, but there are new people on the
thread. Of course it would have been easy to send us to the archives
originally, but I'm pretty sure we recived some comments from Graham and
others that were pretty important and needed to be stated.
Also....I am not bashing anyone, the least of all Graham...like most I
quiver at the thought of meeting such an intellect face to face. I've
tried to read through the source of Inform and would just as soon be
totemized. It is truly mind-bogglingly mind-boggling and I applaud the
accomplishment.
I think my version of a Visual Inform was more of a getting started tool
that would help beginner's become familiar with the compiler and
eventually they would move to a text editor and learn a little oo
programming. As I've stated, I''m way past going back to an editor
myself.
I do however believe that a different manual or an FAQ would help a great
deal. I am willing to be a part of (as time permits) or to organize such
an effort. This would require cooperation from everyone.
So I'm done whining.....the solution is some sort of help guide that is
so simple, that a novice programmer can get their feet wet in Inform. If
we cuold agree to this, I will begin accepting direct e-mails and start
building an HTML version on my companiy web-site (www.placet.com).
And don't worry about offending me with your criticism....I don't take
any of this personally....I just LOVE interactive fiction and I wanted to
get involved...
David A. Cornelson, Chicago
dcorn...@placet.com
In article <66sbkh$ns8$1...@joe.rice.edu>,
lps...@rice.edu (Lucian Paul Smith) wrote:
>
> OK, here are some of my thoughts on the thread, and some suggestions.
>
> First off, it *is* possible to create a work of IF without knowing
> anything about programming. As someone else mentioned, go to
>
> http://homepages.ihug.co.nz/~daleys/ifcollab.html
>
> This is a serious suggestion.
>
> Secondly, I think that compiling a list of common problems and solutions
> is an excellent idea, and one that should be followed up on immediately.
> As I said last time, and which no-one took me up on [*sniff*], go to:
>
> http://c2.com/cgi/wiki?IntFicInformTips
>
> and add your questions and answers directly to the page by clicking on the
> 'EditText' link at the bottom of the page.
>
Nice job!
However (uh-oh)...
I think something more organizaed is necessary to accomplish this task.
The FAQ is still a great idea, but to organize a new manual, someone must
be the editor.
Andrew Plotkin
dcorn...@placet.com wrote:
> Okay, I'm done ranting...I hope no one is mad but I went back through the
> archives and discovered that this conversation happened this past January
> as well.
Probably before that as well. I'm glad our concerted outpouring was...
er... informative. :)
> So I'm done whining.....the solution is some sort of help guide that is
> so simple, that a novice programmer can get their feet wet in Inform. If
> we cuold agree to this, I will begin accepting direct e-mails and start
> building an HTML version on my companiy web-site (www.placet.com).
I hear that Placet is a crazy place.
(Alert: obscure joke! Do not take literally.)
Dave Gatewood
David A. Cornelson wrote:
> The designer's manual is ridiculous. The important parts are
> strewn from one end to the other and it never really answer's questions,
> which is what a user's manual should accomplish.
Actually, I think the DM is absolutely incredible - I mean, you're
telling me that somebody put together this huge detailed instruction
book for free? This isn't one of those half-baked Microsoft manuals
that doesn't even tell you half the commands, or some terse and poorly
indexed help file. Everything is in there (perhaps some would complain
that "everything" is too much), it's well-organized, fully indexed, and
quite readable (even amusing). I consider the DM to be one of Inform's
better selling points.
Yet I can understand the desire for an "Inform for Dummies" book. I
think an appropriate subtitle for it would be: "Programming an
AGT-Quality Game Using Inform." It would appear that there is a growing
audience out there that would like to use Inform, but isn't (for the
time being) interested in doing anything even remotely fancy with it.
That way, even though their games will be primitive, they can still take
advantage of a lot of Inform's built-in quality (such as the parser);
have a large corps of experienced programmers on r.a.i-f to lend a hand
as needed; and, most importantly, leave themselves with room to grow
later, when they do decide to get more "fancy."
I know, I know, the usual argument is that you just can't do *anything*
of substance without understanding a certain amount of real
programming. But I think the "Inform for Dummies" contingent probably
has a different view of what "something of substance" is. (I mean, when
you first started, didn't you get a thrill out of just programming
anything? "Oh my god - I made a lamp! And I can turn it on - and off
again! This is so cool!") So a simpler manual would probably be much
appreciated by many as an early crutch to get going quickly, leaving the
DM as more of a reference manual for specific questions as they crop up.
As far as what should be included in "Inform for Dummies", and how it
should be arranged, I'm reminded of the regular clamoring for some sort
of Inform GUI front end. I think a beginner's manual would work well if
designed to teach specifically those things that could be done with such
a front end, and nothing more. This would be pretty limiting (a good
thing). For example, it would demonstrate:
* A precise structure for an Inform program (where to define constants,
where to include parser/verblib/etc., where to include object
definitions, etc.).
* A precise structure for an object definition
* A list of all (easy) library attributes and what they mean
* A list of all library verbs, and to what input they correspond
* A list of the most common properties (description, initial, before,
after, etc.), each with an example of the proper syntax
* Lots of BRIEF examples of simple object definitions, etc.
Etc. Basically it would boil down to snippets of no-frills code (to
demonstrate syntax) and lists of words (e.g. attributes) that could be
included or not. If done well, a beginner could essentially "cut and
paste" using the example source code in the book. They couldn't do a
whole lot with it, but it would be enough to get them started and keep
their spirits up. A grasp of the basics and a couple of successful
compiles makes the DM a lot less daunting.
The key to making any of this simple is to *leave out lots of
information*. Seriously. For example, if the book included a couple of
pages on doors, it would probably be best if it gave just a simple
definition of "door_to" and "door_dir", a couple of easy examples to
demonstrate the syntax, and left it at that (with a reference to the
appropriate section of the DM for further information).
Dave
Magnus Olsson
In article <EL3F...@undergrad.math.uwaterloo.ca>,
That's part of the point. The rest of the point is that if changed
requirements later on mean that your original list class doesn't work
anymore (or, more likely, that you need more functionality from it),
you can go back and replace it afterwards.
So you're both right: I agree with Richard in that it's an all too
common mistake for new programmers (not only in OOP) that they try to
anticipate all future uses cases, and spend an eternity writing the
Ultimate List Class (or whatever). When instead, with OOP, they could
come back and extend it later.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.
Mary K. Kuhner
>Similarly, a "Visual Inform" with a handy
>little "Room Wizard" would still be able to define complex rooms--but
>would do the simple ones much more quickly.
I have not used a visual code writing interface, but I find this
assertion really surprising--can you write a bit about what it's
like? I find doing simple rooms in Inform *extremely* fast, except
for typing in the descriptions, which no tool will help with.
When I do a room for my current game, I spend about thirty
seconds, I think, typing in keywords. (If this bugged me I would
make a template and copy it in.) Then I spend ten-fifteen
minutes getting the room descriptions right (the current game
has four, for dawn-day-twilight-night) and thinking of a good
"You can't go that way" for various directions.
I guess the biggest speed-up would be that occasionally I want
to link to a room whose name I've forgotten; a visual map would
save me the bother of looking it up. But making room-links
is really a trivial part of the coding. I did all the rooms in
"Kirin's Garden" in one short coding session. Everything since
then has been tinkering the object-interaction code.
Honestly, I look at room coding as a vacation; I have to restrain
myself from coding all the rooms right away in the larger of my
two projects, since I know if I do I'll never get all the
niggly stuff right. (Anyone have advice for an Inform implementation
of a fence with a hole in it, where the player might put something
on the fence *or* in the hole? I ended up with add_to_scope hole,
but it's clunky.)
Mary Kuhner mkku...@genetics.washington.edu
HarryH
In article <kjfair-1212...@ntcs-ip127.uchicago.edu>,
kjf...@midway.uchicago.edu.REMOVEME says...
>
>In article <Pz1k.2$104.1...@news1.atlantic.net>,
>har...@iu.net.idiotic.com.skip.idiotic.com (HarryH) wrote:
>
>>Here's a list of questions that I want answered in the Inform FAQ:
>>1. Easy disambiguation
>
>Disambiguation of what? For the most part, that's built right in.
Sorry. I meant natural selection or whatever it is you call it.
From:
SIT ON CHAIR
which chair do you mean, the tiny chair on top of the shelf, the little chair
in the trunk, the broken chair in the trash can, or the wooden chair in front
of Mr. Mean's (your boss) desk?
To this:
SIT ON CHAIR
[Assuming you mean the wooden chair]
You squirm uncomfortably under the gaze of Mr. Mean.
>>2. Eliza (sample code)
>
>I'm *working* on this. I have the TADS code, but it's not quite a
[snip]
Thank you.
>>3. Dealing with numbers. (53 of this, and 24 of that)
>
>That's actually built in to the library now. It may take a *bit* of
>futzing with the "plural" property, but the parser can handle it.
Absolutely. However, there is a bit of futzing. I'm not saying that I will
personally use it (although that Eliza bit would be nice), but it will be a
tremendous help for people with poor programming skills to be able to find it
easily in FAQ. That is, the FAQ should not duplicate Designer
Manual/Exercises, but rather supplement it, as well as clarifies things.
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Andrew Plotkin
Mary K. Kuhner (mkku...@phylo.genetics.washington.edu) wrote:
> (Anyone have advice for an Inform implementation
> of a fence with a hole in it, where the player might put something
> on the fence *or* in the hole? I ended up with add_to_scope hole,
> but it's clunky.)
Since the fence always stays in the same room, I'd just make the hole a
complete separate object -- not in, on, attached to, or add_to_scoped on
the fence. Make the hole scenery so it doesn't show up in room
descriptions, and there's no problem.
add_to_scope would be the right solution if the fence could be pushed
from room to room, and it was important that the hole follow it. I assume
this is not the case. :)
You'd also want to do something on the fence like
before [;
Receive:
if (receive_action == ##Insert)
<<Insert noun fencehole>>;
];
So that "put x in fence" acts as "put x in hole", but "put x on fence"
does not.
Patrick Kellum
In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>The Metrowerks source editor also does syntax coloring, in multiple
>languages. Does anyone know if the coloring algorithm can be customized?
>(Is ther a resource or template buried somewhere that we can play with?)
And to jump onto this line of chat, GoldED on the Amiga has syntax
colouring (not Inform yet, I'm looking into that) and supports folding
(done wih a section of code, just fold it down to a single line to get it
out of your way, I love that feature).
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
Jeff Johnson
Lucian Paul Smith wrote in message <66sbkh$ns8$1...@joe.rice.edu>...
>Secondly, I think that compiling a list of common problems and solutions
>is an excellent idea, and one that should be followed up on immediately.
>As I said last time, and which no-one took me up on [*sniff*], go to:
>
>http://c2.com/cgi/wiki?IntFicInformTips
>
>and add your questions and answers directly to the page by clicking on the
>'EditText' link at the bottom of the page.
I like it, I like it!
Jay Goemmer
lps...@rice.edu (Lucian Paul Smith) wrote:
>First off, it *is* possible to create a work of IF without knowing
>anything about programming. As someone else mentioned, go to
>
>http://homepages.ihug.co.nz/~daleys/ifcollab.html
>
>This is a serious suggestion.
And a valid one, at that. *However,* if want *wants* to teach oneself
how to program a language (namely, Inform) so they *can* do the actual
programming, one needs to learn the language. (Which I'm trying to do.)
Not that I'm bullheaded, or anything . . . Well, okay, I *am,* but
enough about me. ;-D
>Secondly, I think that compiling a list of common problems and solutions
>is an excellent idea, and one that should be followed up on immediately.
>As I said last time, and which no-one took me up on [*sniff*], go to:
>
>http://c2.com/cgi/wiki?IntFicInformTips
I have duly bookmarked the above URL. Thanks!
--Jay Goemmer
Matthew T. Russotto
In article <EL3F...@undergrad.math.uwaterloo.ca>,
Joe Mason <jcm...@undergrad.math.uwaterloo.ca> wrote:
}In article <66ovls$ses$4...@pump1.york.ac.uk>,
}Richard G Clegg <ric...@manor.york.ac.uk> wrote:
}
}>binary digit class". Or spend the first 3 weeks of any project
}>rewriting their linked list class. Eventually colleagues get together
}
}Ironic, since the whole POINT of OO is to be able to write one linked list
}class that works and never have to rewrite it again...
Of course, we procedural programmers managed that years ago, and
without even a template in sight.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Jeff Hatch
Mary K. Kuhner wrote:
>
> In article <34923C...@hatch.net> je...@hatch.net writes:
>
> >Similarly, a "Visual Inform" with a handy
> >little "Room Wizard" would still be able to define complex rooms--but
> >would do the simple ones much more quickly.
>
> I have not used a visual code writing interface, but I find this
> assertion really surprising--can you write a bit about what it's
> like? I find doing simple rooms in Inform *extremely* fast, except
> for typing in the descriptions, which no tool will help with.
>
> When I do a room for my current game, I spend about thirty
> seconds, I think, typing in keywords. (If this bugged me I would
> make a template and copy it in.) Then I spend ten-fifteen
> minutes getting the room descriptions right (the current game
> has four, for dawn-day-twilight-night) and thinking of a good
> "You can't go that way" for various directions.
Basically the only difference between my version and ordinary systems is
that the thirty seconds is saved. When I create a new object of a
certain class, my system lists the elements of that class underneath the
name of the object in one column, and the default starting values are in
another column. Then the initial values can be set by moving the cursor
to the appropriate location without actually having to type the name of
the attribute you're setting. To change the way a room overrides
certain commands, I just go to the "Commands" function in the list and
press Enter, which takes me into a normal procedural function editor.
Not much use for making rooms, certainly. But it's a bit more useful
when creating rarely used classes, since the pop-up template can save
the trouble of looking up the class's definition. It'll also be a
little easier for non-programmers to get used to, since it works a bit
more like a database.
I personally find some of the side-effects of this approach more useful
than the automatic templates. For instance, since my editor actually
"understands" the structure of my program, I've made the "Delete" key
warn me if I attempt to delete an element that's being used in another
part of the program. (For instance, if I try to delete the "Kitchen"
from the game, and "LivingRoom.East" is set to point to the Kitchen.)
It's not completely "visual," but I think this kind of compromise is
more practical than a full-fledged visual system. Something quite
similar could be implemented in Inform, though without the side-effects
that I enjoy in a language designed for this purpose.
Hopefully I'll be able to prepare a decent demo program by February at
the latest, so you can see for yourself what I'm talking about.
-Rúmil
Magnus Olsson
In article <66vl79$q...@wanda.vf.pond.com>,
Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
>In article <EL3F...@undergrad.math.uwaterloo.ca>,
>Joe Mason <jcm...@undergrad.math.uwaterloo.ca> wrote:
>}In article <66ovls$ses$4...@pump1.york.ac.uk>,
>}Richard G Clegg <ric...@manor.york.ac.uk> wrote:
>}
>}>binary digit class". Or spend the first 3 weeks of any project
>}>rewriting their linked list class. Eventually colleagues get together
>}
>}Ironic, since the whole POINT of OO is to be able to write one linked list
>}class that works and never have to rewrite it again...
>
>Of course, we procedural programmers managed that years ago, and
>without even a template in sight.
Of course. An you keep managing to to it in every new project as well,
just as the OO programmers do. :-)
I thing Richard's quote could be generalized:
"All programmers spend the first 3 weeks of any project rewriting their
linked lists code."
I'm exaggerating just slightly. Programmers do have a tendency to
re-invent the wheel, over and over again. Which costs their customers
billions of dollars each year. To be fair, the supposedly standard
wheels that managers optimistically think can be taken over from the
last project often turn out to be slightly square, which promnpts the
programmers to start inventing hexagonal wheels, when what is needed
really is a *round* wheel.
Jeff Hatch
Alan Conroy wrote:
[David A. Conrelson wrote:]
[snip]
> >Next...after a short burst of energy trying to think up a reasonable
> >graphical interface to Inform, I gave up...for now. The reason? No
> >support from said author. I doubt he understands the need.
>
> assumption? My authoring tool, Adventure Builder, has a Windows GUI
> interface for those who want to use it (and DOS for those who don't).
> But to be candid, the ONLY reason it does have a Windows GUI is
> because I needed a project of sufficient scope to learn the Windows
> 3.1 API.
It suddenly occured to me that maybe there's a simple reason GUI tools
for IF aren't more common--those who have the programming skill to
create them are generally those who need them least. I also started
making a more graphical interface just as an excuse to learn to program
Windows, though later I reverted to DOS and kept the same basic
interface.
-Rúmil
FemaleDeer
The Inform manual has improved through it's various versions, things used to be
scattered around more.
A Dummies Manual, however, would help non-programmers and also might help
clarify some of the simplier, and so sometimes easy to over look, points.
The major thing wrong with the Inform manual is most of the examples ARE for
more difficult things, so examples for simple stuff would be helpful.
1. What I wish I had known -- if the player puts an object on a concealed
supporter or in a concealed container it also becomes concealed, i.e.,
invisible to the player. The player can also not go through a concealed door.
2. Examples for ropes, liquids and conversation (using a topic finder such as
in Christminister) would be helpful. Also something for ladder routines, i.e.
you can "climb" a ladder and go "up" and "down" (the ladder is visible as a
separate object) and end up in a different location (this is harder to code
than it sounds.)
3. A "map" of command processing, what happens after the player enters a
command: the routines the parser calls, descending next to the verbsub
routines (and preprocessing routines like chooseobjects, etc.) then down before
and react_before of rooms and other objects and next NPC processing, if it
involves an NPC. A map with branches showing all this would be very helpful,
currently that is all still scattered throughout the Inform manual.
FD :-)
------------------------------------------------------------------------------
Femal...@aol.com "Good breeding consists in
concealing how much we think of ourselves and how
little we think of the other person." Mark Twain
Andrew Plotkin
Jeff Hatch (je...@hatch.net) wrote:
> It suddenly occured to me that maybe there's a simple reason GUI tools
> for IF aren't more common--those who have the programming skill to
> create them are generally those who need them least.
This probably also explains why GUI tools of *all* sorts are so uncommon.
I mean, er --
FemaleDeer
Well, I posted before I read the whole thread.
So I would just like to add, I have used an Adventure Builder System in the
past (approx. 15 years ago, it was for an Apple and I can't remember the name
of the system -- maybe that was it) and I very quickly wanted to outstrip the
standard things I could do. In other words, I soon became frustrated with what
I couldn't do and wanted to do some actual programming to get more specific
(only I couldn't do it with that enclosed system).
So I simply can't see HOW one could write a game WITHOUT doing some
programming, as there are usually non-standard things in every game. Those can
still be simple things like a liquid or climbing a ladder.
So I personally, want again, to express my gratitude to Graham Nelson for
devoting years to developing Inform and for sharing it freely. It is a very
good (if not perfect) game writing system, but unfortunately, one MUST be able
to program to use it.
Maybe someday, COMPUTERS will be smarter, but the current state of affairs is
we still have to do a lot of it ourselves. (Envisioning a day when we can
really talk to our computers and have them understand us, also envisioning a
day when the whole house -- lights, heat, etc. -- is plugged into our home
netaccessor/tv/computer system.)
Yes, they make our life easier but they still aren't as easy to use as they
could be or will be someday.
Jeremy A.Smith (formerly Rancid the Elf)
Graham Nelson <gra...@gnelson.demon.co.uk> wrote in article
<ant1218031cbM+4%@gnelson.demon.co.uk>...
> My point is just that a non-programming tool can only make the
> first kind of "game", or else copies of what is essentially a
> single original game. The Scott Adams / Brian Howarth games,
> for instance, are basically duplicates of "Adventureland", with
> the essential puzzles -- light and the lamp, treasure collection --
> programmed into the "hardware" of the format. And yet even they
> contain a substantial amount of quite cunning code, and I don't
> think they could be assembled without programming. For example,
> suppose you drop the bees in "Adventureland":
Okay, here's how I'd do it in an Icon-driven, visual language:
> 85) 18 23 [DRO BEE]
List of verbs down left-hand side of screen. List of objects next to it.
User clicks on scroll-bar for list, scrolls down to "Drop" and clicks on
it. Then, on the right, scrolls down to "Bee" and clicks on that. Advantage
here is that the computer keeps track of all objects in the game, so it's
easy to know what it's called, and you don't have to remember the exact
name. Also, the computer can sort objects into an alphabetical ordered
list, which isn't so easy in a text editor!!
> ? HAS (26 = bees in a bottle)
Pick up icon "Condition..." and then click "Player" in objects list,
"Contains" from another list (or a box icon), click on bottle, then click
"Bottle", "Contains", "Bees".
> ? IS_in_AR (27 = large sleeping dragon)
Select room 27, select "Contains", select Dragon.
> -> 53 = MOVE_INTO_AR (24 = large african bees)
Click on Map icon for a computer-drawn map of the game, showing all
connections etc, and pull the bees from the Objects list into the relevant
room.
> -> 53 = MOVE_INTO_AR (44 = *DRAGON EGGS* (very rare))
Move Eggs into relevant room.
> -> 55 = REMOVE (27 = large sleeping dragon)
Pick up Dragon Icon from the required room on the map, and put it in the
wastebasket!!
> -> 43 = PRINT(The bees attack the dragon ....
Click print, type message.
> (I won't reveal what happens in this contingency.) Even these
> minor complexities would stretch the abilities of a purely
> mechanical adventure-creator.
Well, as shown above, it could be easily done using a WIMP interface, given
a bit of careful programming and thought. If I had Visual C++, I'd be
working on it right now!! But such a system does not exist yet.
As for compilation, the program would output TEXT which would then be
compiled using Inform. Simps.
Frankly, even though I am a good OO programmer, I would love such a
program, as hammering away in a text editor for hours is not my idea of
fun. It's easy to forget what tools are for: Not for doing the job, but
making the job easier. I *CAN* dig the garden with a spade, but I'd rather
use a JCB...
--
Jeremy A.Smith
To reply by Email, change the 'z' in lwtcdz to i
alt.public-relations:alt.eating-toothpast:alt.blow-dry-your-own-head
^^^ The above line of text is merely an obscure signature joke^^^
------------------Advent Calendar Issue - 24 Articles day by day--------
http://www.geocities.com/SoHo/7691
http://www.homeusers.prestel.co.uk/lwtcdi/all/
Matthew T. Russotto
In article <670ci9$f1u$1...@bartlet.df.lth.se>,
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
}I'm exaggerating just slightly. Programmers do have a tendency to
}re-invent the wheel, over and over again. Which costs their customers
}billions of dollars each year. To be fair, the supposedly standard
}wheels that managers optimistically think can be taken over from the
}last project often turn out to be slightly square, which promnpts the
}programmers to start inventing hexagonal wheels, when what is needed
}really is a *round* wheel.
<Rant on>
Yeah, yeah, yeah. And in the time it takes for OO programmers to
specify and design the interface for this round wheel, the procedural
programmers have already written three new projects with custom
shaped wheels that were easy to build (particularly when you took
the code base from other wheels). Programming isn't like hardware,
there's little in the way of tooling or production costs, so design
-IS NOT- cheaper than code. This is the fatal mistake all "software
engineering" methodologies make. And those in charge never understand,
because while they are out arguing about the design, their programmers
will get disgusted and go write the code both ways to see which is
better. And the method will get the credit for the success, even
though its violation was the only way anything gets done.
<Rant off>
Laurel Halbany
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>I might say that, like Andrew elsewhere in this thread, I just don't
>believe in this particular Grail. The range of behaviour needed by
>puzzles and activities in a game of any artistic worth exceeds
>the range of behaviour which can be generated by a non-programming
>system.
IMO, the real problem is that the nonprogrammers would be the ones to
use a Visual Inform setup--I suppose it'd have to be called
"Invisible"--but couldn't write it, whereas the programmers, who could
write such a thing, don't need one and so won't.
>My point is just that a non-programming tool can only make the
>first kind of "game", or else copies of what is essentially a
>single original game.
It could provide a setting-off point for writing games, though. If you
had a "Room Wizard" sort of thing, you could create basic rooms
(without worrying about typos), output plaintext code, then manually
fiddle with the code and make it more complex.
----------------------------------------------------------
Laurel Halbany
mythago@twisty_little_maze.com
(Substitute dashes for underscores to remove spamblock)
Laurel Halbany
erky...@netcom.com (Andrew Plotkin) wrote:
>It's probably best to start with a very tiny goal. Make a room. Make a
>button. Make the button go "ping" when you push it. That's not IF, but
>it's a start, and it's exactly what's in the first two chapters of the
>DM's Book Two (the book on "Designing."[*])
I've found that, as with most computer manuals, just reading doesn't
necessarily help. What really helps is to "code along" with the text,
creating your own items following the form of each example. When the
DM explains an initial room, you write your own initial room--then if
it doesn't work as it should, you figure out why it doesn't.
Giles Boutel
Allen Garvin <earendil@> wrote in article
<34914...@news.tamu-commerce.edu>...
> In article <881798985...@dejanews.com>,
> David A. Cornelson <dcorn...@placet.com> wrote:
> >I see the index of such a project as questions...
> >
> >I. Definitions
> > a. What the heck is an Attribute?
> > b. What on earth is a Global?
> > c. Is this my Property or yours?
> >
> >II. Structure of an Inform file
> > a. What does an Inform file look like when you begin coding?
> > b. Where do I put the title information?
> > c. Where do I put Global variables?
> > d. Where do I define Attributes?
> > e. Ditto Properites!
> >
> >III. Mapping out your locations
> > a. How do I create a location
> > 1. It's dark in here...turn on the light!
> > 2. Where's that bathroom that I built?
> > b. There's an awful lot of scenery here but I can't find it!
> > 1. Hey, how come I can pick up this four-poster iron bed?
>
> The Designer's Manual answers all these questions! You can find where the
> answer is to almost every one of these by glancing through the table of
> contents. It's easy to read, well-organized, literate and often humorous.
It
> might be the best tutorial/manual for a language I've ever seen (and most
that
> I've read are abysmal).
>
> I can't see how it can easily be improved upon.
Back when I first started reading this group (I don't want to remember how
long ago that was) - I was your typical Inform Never-Programmed-Before
Newbie. I, too, thought the designer's manual was a little tough on those
without programming experience (the exercises seemed to include elements
that hadn't been mentioned, and the examples would change syntax without
warning, as in "What? That line needs a comma? But it was a semi-colon
before! What gives?")
So, after some discussion on the subject on r.a.i-f, I started to write my
own 'dummies' manual, based on what I picked up as I went along. I think I
got as far as doors before I suddenly realised that I was repeating myself.
The basic elements - those that would be necessary to create, say, Scott
Adams Adventureland, can be picked up pretty easily from the manual, with a
little trial and error. And if you want anything more complicated, you're
not going to get anywhere without understanding those basic elements. This
is where a Visual Inform becomes a risk, IMO, as it removes the necessity
to become fully acquainted with the fundamental elements that make up an
inform game, making extending the basics an even tougher challenge if/when
it becomes necessary.
To my mind, most of the time-consuming stuff about learning Inform (for me,
imho) could have been made easier by three changes to the existing manual
(this is me trying to be constructively critical so please don't flame -
xmas is stress enough :-)
1) Provide exercises that relate purely to what has been covered in that
section or those sections previous. Many of the existing exercises aren't
much good for newbies taking things on-board chapter by chapter.
2) Annotate the code snippets further to explicate syntax, meaning, and end
result.
3) Provide plenty of complete code snippets eg, show complete objects (with
annotation) using the principles being discussed, full examples of verb
creation etc, within the documentation.
Even then, this would be only a refinement of what is already a very
functional document (it must be functional if I managed to work it out :-)
Anyhow - z'ats my 2c
-Giles
-Giles
Giles Boutel
Giles Boutel <bout...@wcc.govt.nz> wrote in article
<01bd08eb$3a6cfd80$6733...@WC034319.wcc.govt.nz>...
>
> Anyhow - z'ats my 2c
>
> -Giles
>
> -Giles
>
Hee hee - don't you just hate repeating yourself :-)
-G
Kenneth Fair
In article <19971214215...@ladder02.news.aol.com>,
femal...@aol.com (FemaleDeer) wrote:
>The major thing wrong with the Inform manual is most of the examples ARE for
>more difficult things, so examples for simple stuff would be helpful.
Agreed. I like having the complex examples, but some simpler ones would
help for those starting out. But this might be soluble with a good library
of introductory objects.
>1. What I wish I had known -- if the player puts an object on a concealed
>supporter or in a concealed container it also becomes concealed, i.e.,
>invisible to the player. The player can also not go through a concealed door.
I still find I have problems with the whole concealed/static/scenery/
transparent/container/supporter distinctions. What *exactly* happens is
sometimes vague, and I just have to try it out and see.
>2. Examples for ropes, liquids and conversation (using a topic finder such as
>in Christminister) would be helpful. Also something for ladder routines, i.e.
>you can "climb" a ladder and go "up" and "down" (the ladder is visible as a
>separate object) and end up in a different location (this is harder to code
>than it sounds.)
Is it? If the ladder is fixed in place, I'd implement it as a door object,
then just add a before rule that traps ##Climb and returns <<Go u_obj>>.
>3. A "map" of command processing, what happens after the player enters a
>command: the routines the parser calls, descending next to the verbsub
>routines (and preprocessing routines like chooseobjects, etc.) then down before
>and react_before of rooms and other objects and next NPC processing, if it
>involves an NPC. A map with branches showing all this would be very helpful,
>currently that is all still scattered throughout the Inform manual.
I *definitely* want this. I'd also like a complete list of global variables
and routines used in the library and what they do.
Of course, to some extent, that's gotten from examining the library files
themselves.
Kenneth Fair
In article <fake-mail-121...@van-as-12a10.direct.ca>,
fake...@anti-spam.address (Neil K.) wrote:
>kjf...@midway.uchicago.edu.REMOVEME (Kenneth Fair) wrote:
>
>> With respect to syntax coloring on the Mac: I use BBEdit to program Inform,
>> as I suspect a number of other Mac Informers do. BBEdit already has
>> built-in syntax coloring for C/C++, Pascal, and HTML. Perhaps if you
>> gave them your algorithm they could include Inform syntax coloring?
>
> I asked them if they'd consider adding TADS syntax colouring or provide
>facilities for customizing syntax colouring, but they said they had no
>plans to do so. TADS has too small an audience (as does Inform, I'm sure)
>to justify the effort and their current syntax-colouring scheme is
>apparently too hardcoded to make it generalizable, if there were such a
>word. Oh, well.
I figured as much. I though they _might_ be willing to consider it if
the algorithm was already figured out and they just had to plug it in.
Oh well.
Magnus Olsson
In article <672agq$e...@wanda.vf.pond.com>,
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>
>}I'm exaggerating just slightly. Programmers do have a tendency to
>}re-invent the wheel, over and over again. Which costs their customers
>}billions of dollars each year. To be fair, the supposedly standard
>}wheels that managers optimistically think can be taken over from the
>}last project often turn out to be slightly square, which promnpts the
>}programmers to start inventing hexagonal wheels, when what is needed
>}really is a *round* wheel.
>
><Rant on>
>Yeah, yeah, yeah. And in the time it takes for OO programmers to
>specify and design the interface for this round wheel, the procedural
>programmers have already written three new projects with custom
>shaped wheels that were easy to build (particularly when you took
>the code base from other wheels).
This is really not a qeustion of OO vs. procedural, but of different
schools of rigid vs. not-so-rigid design methods. Mis-management,
over-design and overly rigid "waterfall" design methodologies (like:
"design everything first, and have the designs go up and down through
the chain of command, gaining stampsof approval from everybody, before
you write a single line of code) are deleterious to any project.
And, to continue the "wheels" example, design doesn't really help.
Isn't it usually like this: Managers optimistically think that the
wheels from the last project can be re-used (especially since they've
heard a lot of hype about OO and reusability). The designers ignore
this and spend a lot of time designing new wheels, that turn out to be
square. The programmers try to implement this, find out that it won't
work, and make elliptical wheels instead. When these don't work
either, a frantic effort is made to reuse the wheels from the last
project - which takes five times as much time as predcited, and when
it's finished, these wheels turn out to octagonal. Programmers are
sent in to file of the corners of the octagons by had, which makes for
a bumpy ride but at least it works, sort of. Afterwards, everybody
agrees that they should have made round wheels from the
start. Everybody except for the customer, of course, who really wanted
caterpillar tracks.
Isn't that how software development really works? :-)
Some practical data points: the project I'm currently involved in is
now up to about 500k lines of C++. We've tried doing everything by the
book and following an incremental design model, with design meetings,
prototyping, reviews and everything. It turned out that the only way
to get things done was for everybody to sit down and start
programming. In effect, all attempts at formal software engineering
have just bogged the project down. The design has effectively been
delegated to the individual programmers (with frequent coordination
meetings, of course).
But this has nothing to do with OO vs. non-OO *programming* (as opposed
to design). In fact, our programmers seem unanimous in that OOP is
superior to procedural programming (for our project, at least) and
that without OO, we wouldn't have been able to pull it off. Of ocurse,
your mileage may vary.
Fortunately for most readers of this group, these problems don't start
appearing until the project is several orders of magnitude larger than
even the most ambitious text adventure. I don't think IF programmers
need to worry about software engineering paradigms very much - yet.
But I'm firmly convinved that for IF programming, OOP is very natural
and serves to simplify things. OOP was invented for simulations, and
IF is basically about simulating a world. Simulation problems simply
map well to an OO formulation.
Andy Wright
Laurel Halbany wrote:
...
>
> It could provide a setting-off point for writing games, though. If you
> had a "Room Wizard" sort of thing, you could create basic rooms
> (without worrying about typos), output plaintext code, then manually
> fiddle with the code and make it more complex.
>
> Laurel Halbany
> mythago@twisty_little_maze.com
> (Substitute dashes for underscores to remove spamblock)
There's a mapping tool already on GMD (IFMap, I think) which (according
to the author) will one day be able to output the design as Inform room
code. Tools like this will provide a useful framework for a game but, of
course, won't really lighten the programming load.
Andy
Allen Garvin
In article <01bd08d7$5d62f880$LocalHost@default>,
Jeremy A.Smith (formerly Rancid the Elf) <jeremy...@lwtcdz.prestel.co.uk> wrote:
>Okay, here's how I'd do it in an Icon-driven, visual language:
>
>> 85) 18 23 [DRO BEE]
>
>List of verbs down left-hand side of screen. List of objects next to it.
>User clicks on scroll-bar for list, scrolls down to "Drop" and clicks on
>it. Then, on the right, scrolls down to "Bee" and clicks on that. Advantage
>here is that the computer keeps track of all objects in the game, so it's
>easy to know what it's called, and you don't have to remember the exact
>name. Also, the computer can sort objects into an alphabetical ordered
>list, which isn't so easy in a text editor!!
*snip snip lots of mouse manipulation*
>Frankly, even though I am a good OO programmer, I would love such a
>program, as hammering away in a text editor for hours is not my idea of
>fun. It's easy to forget what tools are for: Not for doing the job, but
>making the job easier. I *CAN* dig the garden with a spade, but I'd rather
>use a JCB...
Sounds like a LOT more work to me. Typing that out wouldn't take more than
a few seconds. Manipulating your way through tens or hundreds of menus and
icons is time-consuming, and clumsy if you don't give it your full attention.
--
Allen Garvin kisses are a better fate
--------------------------------------------- than wisdom
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil e e cummings
Miron Schmidt
> > For example, suppose you drop the bees in "Adventureland":
>
>
> > 85) 18 23 [DRO BEE]
>
> List of verbs down left-hand side of screen. List of objects next to it.
> User clicks on scroll-bar for list, scrolls down to "Drop" and clicks on
> it. Then, on the right, scrolls down to "Bee" and clicks on that.
"Drop an object that has the property 'kills dragon'"?
"Drop an object that is alight *and* has the property 'dragon-proof'"?
"Drop any two objects with a total weight of 19 or more"?
You see, it's awfully easy to come up with examples that any visual system
you describe won't be able to cope with.
(Of course, you can provide the user with a list of 24,000 alternatives in
the object field, listing every possible combination of attributes, objects,
or routines. I'd go back to my text editor in that case.)
> Well, as shown above, it could be easily done using a WIMP interface, given
> a bit of careful programming and thought. If I had Visual C++, I'd be
> working on it right now!! But such a system does not exist yet.
But the shortcomings of that system would become apparent very soon, so you'd
have to drop your tool and return to a slightly less-visual interface.
In any case, "Call the dropped_at_dragon routine of the dropped object if it
provides one and let the object deal with the results itself".
--
Miron Schmidt <mi...@comports.com> PGP key on request
WATCH TV... MARRY AND REPRODUCE... OBEY... PLAY INTERACTIVE FICTION...
Mary K. Kuhner
Jeremy A.Smith (formerly Rancid the Elf) <jeremy...@lwtcdz.prestel.co.uk> wrote:
>List of verbs down left-hand side of screen. List of objects next to it.
>User clicks on scroll-bar for list, scrolls down to "Drop" and clicks on
>it. Then, on the right, scrolls down to "Bee" and clicks on that. Advantage
>here is that the computer keeps track of all objects in the game, so it's
>easy to know what it's called, and you don't have to remember the exact
>name. Also, the computer can sort objects into an alphabetical ordered
>list, which isn't so easy in a text editor!!
This sounds great for a small project, but would it scale up? If
you have several hundred objects in your game, scrolling down a list
of them each time you need to refer to one sounds positively
agonizing. Similarly for the linked map of rooms, when you have too
many rooms to fit on one screen.
You almost surely do *not* want to sort objects into an alphabetical
ordered list in a large game, at least if it is a large segmented
game such as _Jigsaw_ or _So Far_. You want them arranged by the
game region they are in, so that you won't have to wade through hosts
of irrelevant objects to get to the stuff you are working on.
On the other hand, if it's a beginner's system you don't need to worry
about large games, and in fact might do well to discourage them.
Mary Kuhner mkku...@genetics.washington.edu
Joe Mason
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>
>I hear that Placet is a crazy place.
Placet IS a crazy place. I love it!
>(Alert: obscure joke! Do not take literally.)
Oh, fine then. I won't. I quit.
Joe
David A. Cornelson
In article <01bd08d7$5d62f880$LocalHost@default>,
>
Okay, I'm back, dodging and weaving through this thread...
My description of a Visual Inform is NOT to take the place of coding. It
would be intended to AUGMENT the coding itself. In other words, you're
still going to have to learn the language and write code, but there would
be "tools" that would allow you to do some of the mundane tasks more
quickly. My interface would be something like...
- The entire screen is relative to ONE object. - Text boxes for - <name>
- <short desc> - <long desc/[ desc function ]> - Drop Down List Box
containing (before, after, etc.) - with a text box for funciton code -
List Box with multiple select ability that contains Attributes (pos/neg)
- Labels for each direction, next to which is a button with the current
location that direction takes you to. Click the button and THAT location
object appears on the form. Another button next to each direction would
be labeled "Change" which when clicked would give you a list of
"location" objects to choose from (highlighting rooms that are already
connected on the other side)
This sort of interface does not "take away" any level of programing. You
simply have something that "organizes" the language for you. Someone
mentioned in another portion of the thread that it would be "like a
database", and that is exactly the sort of interface I have been talking
about.
You still have to learn the code...but if you had an interface that
organized it and had "help" button to tell you what is what, this would
improve everyone's game writing.
IMHO
David A. Cornelson, Chicago
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
David A. Cornelson
In article <672agq$e...@wanda.vf.pond.com>,
russ...@wanda.vf.pond.com (Matthew T. Russotto) wrote:
>
<snip>
> This is the fatal mistake all "software
> engineering" methodologies make. And those in charge never understand,
> because while they are out arguing about the design, their programmers
> will get disgusted and go write the code both ways to see which is
> better. And the method will get the credit for the success, even
> though its violation was the only way anything gets done.
>
<rant on>
This is my bread and butter and I completely disagree and I can prove
this one wrong. Hacking, as it were, is simply too expensive. If you sit
down and try to add a subsystem to someone elses billing system and
decide that you're going to try it three times and eventually get it
right, you're going to fail...period.
Engineers (as you sneer), walk through every little bitty piece of code
over and over and write a draft of what they believe is a sound design
(in english mind you) of a workable solution. Then the engineer walks
through the "entire" system, all the time verifying that each new
component will work properly with the previous components. In many cases,
this process higlights mistakes and misunderstandings, both in the new
code AND in the old code. Thus you have "issues". Issues then turn into
meetings and yes, it takes time. But eventually you complete the project.
Now I believe there are engineers that get caught up in the process and
forget deadlines. That IS unfortunate. But that has become a very big
no-no in the consulting world. Deadlines are critical.
So the argument is that you can write code 75% of the time, test it, and
complete it without much time for design.
OR, you can design for 90% of the time and what you fail to understand is
that when a design is well done (or medium well, depending on your
tastebuds), testing is an afterthought and takes a very minimal amount of
time. Certainly the risk of surprises is decreased tremendously. But even
with a surprise or two, a design can recover....hacking tends to need
patching and eventually fails to meet the requirements of the system.
I used to hack. I now write designs and discuss issues with people over
and over until they hate me. I write systems in about a fourth of the
time it used to take, much less aspirin involved, and I get paid about
three times as much money. Figure that out....
You will not become a Jedi unless you master the force.
Jeff Hatch
Andrew Plotkin wrote:
>
> Jeff Hatch (je...@hatch.net) wrote:
>
> > It suddenly occured to me that maybe there's a simple reason GUI tools
> > for IF aren't more common--those who have the programming skill to
> > create them are generally those who need them least.
>
> This probably also explains why GUI tools of *all* sorts are so uncommon.
>
> I mean, er --
My theory is that most GUI tools which do exist get made for the money
involved, not for the programmer's benefit, and GUI IF tools wouldn't
make anyone enough money to be worth the trouble. It's just a theory.
-Rúmil
Jeff Hatch
Laurel Halbany wrote:
[snip]
> It [a "non-programming tool"] could provide a setting-off point for writing games, though. If you
> had a "Room Wizard" sort of thing, you could create basic rooms
> (without worrying about typos), output plaintext code, then manually
> fiddle with the code and make it more complex.
That's exactly what I think, except that the Room Wizard could also have
some text editor features, allowing you to fiddle while you're still in
the Room Wizard. That'd be easier if Inform were designed to work in a
more visual manner, but I think it's possible regardless.
-Rúmil
Jeff Hatch
[Digression on object-oriented programming...]
Matthew T. Russotto wrote:
[snip]
> <Rant on>
> Yeah, yeah, yeah. And in the time it takes for OO programmers to
> specify and design the interface for this round wheel, the procedural
> programmers have already written three new projects with custom
> shaped wheels that were easy to build (particularly when you took
> the code base from other wheels). Programming isn't like hardware,
> there's little in the way of tooling or production costs, so design
> -IS NOT- cheaper than code. This is the fatal mistake all "software
> engineering" methodologies make. And those in charge never understand,
> because while they are out arguing about the design, their programmers
> will get disgusted and go write the code both ways to see which is
> better. And the method will get the credit for the success, even
> though its violation was the only way anything gets done.
> <Rant off>
Well, if the OO programmers waste time specifying the perfect interface
before they get started. Usually the interface you want is quite
obvious. Now that I've switched from C to C++, I'm able to program far
more quickly with fewer bugs because of C++'s object-oriented features.
Whenever I create a new feature, I create it using a "quick-and-dirty"
method. Because of encapsulation, I'm able to easily replace that
method with a more efficient technique later if necessary. So it turns
out that I waste less time in advance planning using an object-oriented
language.
So I'd make the first wheel as quickly as any procedural programmer.
Once I realized I'd need two different wheels, I'd abstract the common
attributes from the specific case of the first wheel into a wheel class,
and then I'd be able to create the two new wheels quite quickly using
that class. Faster than making three wheels, once you're good at it.
-Rúmil
Gareth Jones
jcm...@undergrad.math.uwaterloo.ca (Joe Mason) writes:
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >I hear that Placet is a crazy place.
> >(Alert: obscure joke! Do not take literally.)
>
> Oh, fine then. I won't. I quit.
I think that's a swell idea.
--
Gareth Jones <gd...@gdjones.demon.co.uk>
Jeremy A.Smith (formerly Rancid the Elf)
Joe Mason <jcm...@undergrad.math.uwaterloo.ca> wrote in article
<EL7ou...@undergrad.math.uwaterloo.ca>...
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >
> >I hear that Placet is a crazy place.
>
Fredric Brown, 1946?
>
> >(Alert: obscure joke! Do not take literally.)
>
> Oh, fine then. I won't. I quit.
Not obscure enough for me!! Ah, a wise guy, eh? Take that (slap!) and that
(thwap!) and so on...
Andrew Plotkin
Jeremy A.Smith (formerly Rancid the Elf) (jeremy...@lwtcdz.prestel.co.uk) wrote:
> Joe Mason <jcm...@undergrad.math.uwaterloo.ca> wrote in article
> <EL7ou...@undergrad.math.uwaterloo.ca>...
> > In article <erkyrathE...@netcom.com>,
> > Andrew Plotkin <erky...@netcom.com> wrote:
> > >
> > >I hear that Placet is a crazy place.
> >
> > Placet IS a crazy place. I love it!
> Fredric Brown, 1946?
> Not obscure enough for me!! Ah, a wise guy, eh? Take that (slap!) and that
> (thwap!) and so on...
Very good. Heh. Although I'm pretty sure that the last sentence was "I
like it."
Matthew T. Russotto
In article <882258882...@dejanews.com>,
David A. Cornelson <dcorn...@placet.com> wrote:
}meetings and yes, it takes time. But eventually you complete the project.
}Now I believe there are engineers that get caught up in the process and
}forget deadlines. That IS unfortunate. But that has become a very big
}no-no in the consulting world. Deadlines are critical.
Oh, consulting and software design... now there's a combination.
}So the argument is that you can write code 75% of the time, test it, and
}complete it without much time for design.
}
}OR, you can design for 90% of the time and what you fail to understand is
}that when a design is well done (or medium well, depending on your
}tastebuds), testing is an afterthought and takes a very minimal amount of
}time. Certainly the risk of surprises is decreased tremendously.
Right, sure. Such is the theory. But design is so far removed from
the actual system that it isn't the case. You can (and will) design a system
which looks great from a design standpoint, but simply will not work.
Consider a carpenter told to build an object from a drawing of the
Devil's Trident (which has two prongs at one end, yet ends in three).
}I used to hack. I now write designs and discuss issues with people over
}and over until they hate me. I write systems in about a fourth of the
}time it used to take, much less aspirin involved, and I get paid about
}three times as much money. Figure that out....
The money part? That's easy. Designers have worked out a terminology
and a system that sounds wonderful. It breaks software down into the
nice little steps that managers like, and provides timetables and
such. Management will pay for that stuff even if it is wholly
fictional.
Andrew Plotkin
Matthew T. Russotto (russ...@wanda.vf.pond.com) wrote:
> In article <882258882...@dejanews.com>,
> David A. Cornelson <dcorn...@placet.com> wrote:
> }So the argument is that you can write code 75% of the time, test it, and
> }complete it without much time for design.
> }
> }OR, you can design for 90% of the time and what you fail to understand is
> }that when a design is well done (or medium well, depending on your
> }tastebuds), testing is an afterthought and takes a very minimal amount of
> }time. Certainly the risk of surprises is decreased tremendously.
> Right, sure. Such is the theory. But design is so far removed from
> the actual system that it isn't the case.
I have decided that this argument is an illusion.
I am a hacker. I spend 100% of my work time hacking. How much time do I
spend typing with my left hand, as opposed to my right hand? The question
is pointless.
You may judge this approach on its theoretical merits, or on its results.
By the way, a friend was watching me type last week, and she pointed out
that I type with six fingers -- all five fingers on my left hand, and my
right index finger. I divide the keyboard in half in the usual
touch-typing way (although I don't in fact touch-type), but all the keys
on the right half are hit with my index finger.
I was astounded. I've certainly had this habit for at least nine years,
more likely fifteen. The total *continuous* time I've spent in front of a
keyboard must certainly be measured in years. Once it was pointed out, it
was as plain as the, as, as the fingers on my right hand. And yet I never,
never noticed it on my own.
A very Zen moment.
Graham Nelson
>
> I was astounded. I've certainly had this habit for at least nine years,
> more likely fifteen. The total *continuous* time I've spent in front of a
> keyboard must certainly be measured in years.
Andrew, you need to get out more.
> POT, CALL KETTLE BLACK
Done.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
David A. Cornelson
In article <677omu$n...@wanda.vf.pond.com>,
>
Interesting comment. Shows your depth.
>
> Right, sure. Such is the theory. But design is so far removed from
> the actual system that it isn't the case. You can (and will) design a system
> which looks great from a design standpoint, but simply will not work.
> Consider a carpenter told to build an object from a drawing of the
> Devil's Trident (which has two prongs at one end, yet ends in three).
>
<rant>
You don't understand. When I say we "test" the system design, I mean we
walk through each design phase (directly related to lines of code) and
check logic. This is a fairly intense and tedious process but the rewards
of such an effort almost always iron out unforseen problems. When you're
hacking, you can code through 80% of a system and realize that some
portion of your assumptions while you've been hacking are simply not
going to work. What do you do then? Rewrite a major portion of your code
to accomodate the missed assuption, or do you "lie" and work around it.
Designs rarely have such problems if they are done well, and the
walkthrough's were thorough.
I've been in your shoes and quite frankly, you're kidding yourself. You
have assumed the philosophy of "I don't think I can learn anything that
will make me a better developer", when the truth is you're lazy and you
DON'T WANT TO LEARN. This is a discipline like any other effort. What
would a house look like if no one used a "plan". You explain to me the
difference in level of complexity between a house and a system. There is
none. This is not an emotional issue. You simply design it, test your
design thoroughly by walking through the logic, and then you build it,
and test it.
> The money part? That's easy. Designers have worked out a terminology
Yes, it's a conspiracy and we're all whores. I'm offended by this
statement. You've just insulted a few million people that work very hard
and create extremely complex business systems that make people's jobs
better and save corporations a ton of money.
The truth is that "hacking" is dying and you're afraid. You have no idea
how to design a system and in your heart you believe that you can do a
better job than someone that designs a system first. You don't understand
why people need designs and you don't want to inquire. I say wake up.
Businesses are based on what can be seen, milestones as it were. It is
not a "trust" issue. If I rely on you to build a system by hacking, what
happens if you quit in the middle. Then someone else has to pick up your
code and figure it out. Without a design that could take months and
years. This costs money. With a design, developers have the ability to
pick up where someone else left off fairly quickly. Add to that the
maintenance cost saved by having detailed documentation on the "logic" of
a system and your arguments fall flat in the ears of someone spending
tens of thousands of dollars on changing the way they do business.
You can argue all you want but no business that I know would give you the
time of day unless you knew what a Functional Specification, Business
Processes Design, High Level Design, Detailed Design, and Acceptance Test
Plan looked like and knew how to write them as you developed their
systems.
</rant>
Edan
myt...@agora.rdrop.com (Laurel Halbany) writes:
>IMO, the real problem is that the nonprogrammers would be the ones to
>use a Visual Inform setup--I suppose it'd have to be called
>"Invisible"--but couldn't write it, whereas the programmers, who could
>write such a thing, don't need one and so won't.
IMNSHO, a "Visual Inform" won't make programing easy, nor will it teach it.
The best it can do is make repetitious tasks quicker and less boring. The
Underlying problem of whether or not someone can make a game with or
without such a product is the same. You won't be able to turn out
Trinity by just using inform and not learning (and I mean learning from
both reading up and experience) programming, styles, concepts, etc.
This is not to say that you need to be an excellent programmer to turn out
a good piece of IF. Indeed, there are a number of games I have seen that
rely more on the writing than on the programming. However, to turn out
an exceptional game, IMHO, you better be able to program, with or without
Visual Inform.
Until someone can create an Artificially Intelligent Text Adventure maker,
we won't be seeing any programs that can create a game for you just by giving
it a simple description. (Although some companies have been able to get
around this by hiring programmers ;-))
Edan Harel
Edan
mkku...@phylo.genetics.washington.edu (Mary K. Kuhner) writes:
>I have not used a visual code writing interface, but I find this
>assertion really surprising--can you write a bit about what it's
>like? I find doing simple rooms in Inform *extremely* fast, except
>for typing in the descriptions, which no tool will help with.
Yes there are. They're called a dictionary, a theasurus and your
imagination.
Edan "wiseguy" Harel
Andrew Plotkin
Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
> "The Advanced Informer's Guide to Love" might be of greater
> social utility, though.
Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin
> <URL:mailto:erky...@netcom.com> wrote:
> >
> > The total *continuous* time I've spent in front of a
> > keyboard must certainly be measured in years.
>
> Andrew, you need to get out more.
>
> > POT, CALL KETTLE BLACK
> Done.
Let's not beat the horse-grease *too* far into the pavement, now.
Anyway, you're married, I seem to recall. So I don't needta hear any more
on this from ya, ok?
--Z
(Unless, of course, you're actually planning to *write* _The Advanced
Informer's Guide to Love_. "Halfway between Mr. Blobby's *Other* Book of
Computer Fun, and...?")
--Z
(Actually, I was just remarking yesterday that the "Cinderella" picture
on the cover of Hopcroft & Ullman's old parser textbook was really an
out-of-context illustration from an explicit sex manual. Page 37 of the
Parser Kama Sutra, you know. The back cover is page 52. You'll *never*
believe what happens in between--)
Jeremy A.Smith (formerly Rancid the Elf)
Andrew Plotkin <erky...@netcom.com> wrote in article
<erkyrathE...@netcom.com>...
> > Fredric Brown, 1946?
>
> Very good. Heh. Although I'm pretty sure that the last sentence was "I
> like it."
Yeah, "Placet is a crazy place. I like it.". I'd dig the book out (Isaac
Asimov's Before the Golden Age), but it's at the bottom of a box
somewhere!! Long live 30's pulp sci-fi, it was the best (in my opinion).
Matthew T. Russotto
In article <882391048...@dejanews.com>,
David A. Cornelson <david_x_...@amoco.com> wrote:
}In article <677omu$n...@wanda.vf.pond.com>,
} russ...@wanda.vf.pond.com (Matthew T. Russotto) wrote:
}>
}>
}> Oh, consulting and software design... now there's a combination.
}>
}
}Interesting comment. Shows your depth.
}
}>
}> Right, sure. Such is the theory. But design is so far removed from
}> the actual system that it isn't the case. You can (and will) design a system
}> which looks great from a design standpoint, but simply will not work.
}> Consider a carpenter told to build an object from a drawing of the
}> Devil's Trident (which has two prongs at one end, yet ends in three).
}>
}
}<rant>
}
}You don't understand.
I do.
}When I say we "test" the system design, I mean we
}walk through each design phase (directly related to lines of code) and
}check logic. This is a fairly intense and tedious process but the rewards
}of such an effort almost always iron out unforseen problems.
Since you're doing this by hand rather than on the system, you can't
possibly check everything. You can make a beautiful design which
simply can't be built. The tools don't exist for software design that
exist for e.g. building design.
}When you're hacking, you can code through 80% of a system and realize
that some portion of your assumptions while you've been hacking are simply not
}going to work.
Whereas the same thing happens if you went through the whole design
process, except that you've got a lot more to redo. Unless you decide
to simply implement the system the way it can be implemented and let
the design lie.
}What do you do then? Rewrite a major portion of your code
}to accomodate the missed assuption, or do you "lie" and work around it.
}Designs rarely have such problems if they are done well, and the
}walkthrough's were thorough.
}
}I've been in your shoes and quite frankly, you're kidding yourself. You
}have assumed the philosophy of "I don't think I can learn anything that
}will make me a better developer", when the truth is you're lazy and you
}DON'T WANT TO LEARN.
I've seen this emphasis on software design bog projects down to
a standstill, at which point they had to be rescued by "hacking".
}This is a discipline like any other effort. What
}would a house look like if no one used a "plan".
Software isn't a house. If it were as easy to build and tear down a
house as it is to design one on paper, no one would bother designing
one on paper.
}> The money part? That's easy. Designers have worked out a terminology
}
}Yes, it's a conspiracy and we're all whores.
I don't recall using either term.
}I'm offended by this statement.
Then you shouldn't have made it.
}The truth is that "hacking" is dying and you're afraid.
Before I got some practical experience with software design, I was a
bit apprehensive. It looked like someone had figured out how to take
something as enjoyable as programming and turn it into pure tedium.
That was the promise and the object -- to make programming into
unskilled labor. After seeing a few projects developed using that
methodology come in behind schedule and overbudget, with much of the
design ending up scrapped in order to get the thing done, I no longer
have any fear.
}Businesses are based on what can be seen, milestones as it were. It is
}not a "trust" issue. If I rely on you to build a system by hacking, what
}happens if you quit in the middle. Then someone else has to pick up your
}code and figure it out. Without a design that could take months and
}years. This costs money. With a design, developers have the ability to
}pick up where someone else left off fairly quickly. Add to that the
}maintenance cost saved by having detailed documentation on the "logic" of
}a system and your arguments fall flat in the ears of someone spending
}tens of thousands of dollars on changing the way they do business.
Right. Maybe they'll listen to me later, when their product is 2
years late and still in the design phase, with all their best people
getting sick of the whole thing and heading off to the competition.
}You can argue all you want but no business that I know would give you the
}time of day unless you knew what a Functional Specification, Business
}Processes Design, High Level Design, Detailed Design, and Acceptance Test
}Plan looked like and knew how to write them as you developed their
}systems.
Yes, I've admitted the terminology sounds great to management.
Mark J Musante
David A. Cornelson (david_x_...@amoco.com) wrote:
> The truth is that "hacking" is dying and you're afraid.
As long as there are computers, as long as there is new hardware and
software to play with, there will always be "hacking".
-=- Mark -=-
Graham Nelson
In article <erkyrathE...@netcom.com>, Andrew Plotkin
<URL:mailto:erky...@netcom.com> wrote:
> Let's not beat the horse-grease *too* far into the pavement, now.
Bzzt -- Americanism out of range -- bzzt -- does not compute --
> Anyway, you're married, I seem to recall. So I don't needta hear any more
> on this from ya, ok?
Nope, I am quite, quite single, though I do exchange amorous letters
with one Angela M. Horns of the Isle of Eigg -- mostly about knitting
patterns and peat cultivation, it's true, but we're shy souls at
heart. It's an English thing.
> --Z
>
> (Unless, of course, you're actually planning to *write* _The Advanced
> Informer's Guide to Love_. "Halfway between Mr. Blobby's *Other* Book of
> Computer Fun, and...?")
Now it might be quite amusing setting the double-triangle exercises,
admittedly. "... and with your _left_ ankle, ..."