NLP Question

167 views
Skip to first unread message

John

unread,
Jul 4, 2002, 3:35:53 PM7/4/02
to
All,

I am interested in writing my own text adventure. I have done some research
including looking at various text adventure creation systems, but not found
the information I am looking for.

I would like to create the piece that understands what the user is
requesting and that maps that to nouns, verbs etc. Basically the
interpreter. For various reasons I would like to do this in Java. I have
the programming skills, just not the natural language processing skills.

It would seem that this has been done a number of times with each of the
systems. The problem I have found though is that this code is not visible.
People create these scripts and the builder takes those and creates a
mechanism to parse the users input.

I would appreciate any pointers to either opensource projects or other
information in this area. Also if there are good natural language
processing books geared to text adventures I would also be interested.
Also, if there is a better place to ask this question please let me know.

TIA,
John.


Daniel

unread,
Jul 4, 2002, 4:47:32 PM7/4/02
to
On Thu, 04 Jul 2002 19:35:53 GMT, "John" <nojgoa...@hotmail.com>
wrote:

<snip>


>I would like to create the piece that understands what the user is
>requesting and that maps that to nouns, verbs etc. Basically the
>interpreter. For various reasons I would like to do this in Java. I have
>the programming skills, just not the natural language processing skills.

The amount of code involved in a true nlp parser is going to be a
serious pain. Both for you as the author of it and the end user as the
person who has to download endless megabites of language trees. Also
it will probably not be used much both for the reason above and
because of the fact that the existing parsers already come close
enough to language parsing to be acceptable to the majority of authors
and players.

That said there is a fairly large open source nlp project that I think
could be easily (using the word easily in a purely comparitive sense)
modified to accept text adventure environments.

Check out A.L.I.C.E. Program D. The website is at
http://alice.sunlitsurf.com/ and there is an active mailing list that
I'm sure would be more than happy to help you when you get stuck. The
project is designed as a conversational bot, and there is probably a
good portion of its brain that you'll be able to delete as unimportant
in an IF format. It is java based though and open source, along with
having, as mentioned before, an active and supportive community of
programers. From what I hear it is also fairly easy to modify the
Alice brain for specific tasks, this feature is usually used to set up
the bot as a website guide or information database for businesses but
I see no reason why you wouldn't be able to use the language parsing
as the first step in an nlp IF parser.

<snip>


>I would appreciate any pointers to either opensource projects or other
>information in this area. Also if there are good natural language
>processing books geared to text adventures I would also be interested.
>Also, if there is a better place to ask this question please let me know.

I don't think I've seen any nlp projects specifically geared towards
IF beyond the basic verb-noun parsing that the existing games depend
on. A true nlp IF parser would probably open up IF games to a wider
audience, including the vast majority of friends and family members
that I periodically con into sitting down to a text game only to have
them type in something like "walk forward" or "ask the woman where the
key is" and then give up when it doesn't do what they had in mind.


---Daniel
erthwin at cox dot net

Left, left, I hadda good brain but it left...

John

unread,
Jul 4, 2002, 7:13:31 PM7/4/02
to
Daniel,

I am happy to go with something reasonably simple. If I could approach the
sophistication of the infocom games it would be awesome. More than that is
not necessary. I am targetting existing players for the most part. I am
trying to achieve something quite different than the current text adventure
games, that hopefully people will like.

One of my many concerns is the many megabytes of download. I need to keep
things small. I am using Java so that works out good.

Thanks for the link, I will check that out.

John.

<Daniel Fr...@dev.nul> wrote in message
news:3d24d781...@news.east.cox.net...

John

unread,
Jul 4, 2002, 8:06:25 PM7/4/02
to
I checked out the A.L.I.C.E project. A very good project. I realize though
that they are doing pattern matching. If I am not wrong, they are basically
matching user input with pre-defined symbols. There is no grammar
understanding as far as I saw.

I guess what I need is a way to determine the nouns, verbs, etc. from a
sentence. From then I can pretty much deal with the input. Is this what
the infocom adventures did? Or was it purely a matching of the game
definition text with the user input?

Again, any pointers very appreciated.

John.

"John" <nojgoa...@hotmail.com> wrote in message
news:vE4V8.344$Yx5...@newsread1.prod.itd.earthlink.net...

Daniel

unread,
Jul 4, 2002, 8:16:18 PM7/4/02
to
On Fri, 05 Jul 2002 00:06:25 GMT, "John" <nojgoa...@hotmail.com>
wrote:

>I checked out the A.L.I.C.E project. A very good project. I realize though
>that they are doing pattern matching. If I am not wrong, they are basically
>matching user input with pre-defined symbols. There is no grammar
>understanding as far as I saw.

Hmmm..it has been a while since I last checked on alice..I guess my
memory was off then. I thought I remembered the original input text
being parsed and then sent to a pattern recognition bit and I was
assuming you could use the initial parsing to do what you intended.

>I guess what I need is a way to determine the nouns, verbs, etc. from a
>sentence. From then I can pretty much deal with the input. Is this what
>the infocom adventures did? Or was it purely a matching of the game
>definition text with the user input?

It occurs to me that if all you want is a parser to equal that of the
Infocom games then any of the existing parsers are fully up to the
task. What exactly is it that you want this program to do that TADS or
Inform (or most of the others) can't?

John

unread,
Jul 4, 2002, 8:41:28 PM7/4/02
to
I didn't spend very long on the alice site. I read a couple of the docs. I
will go back again to make sure I didn't miss something.

I have not been able to find source for the existing parsers in a form that
would be understandable without spending as much time as writing it in the
first place.

I have always liked the infocom adventures and always wanted to create my
own. I have some ideas on some things I would like to do differently.

John.

<Daniel Fr...@dev.nul> wrote in message

news:3d250e22...@news.east.cox.net...

Sascha Müller

unread,
Jul 5, 2002, 4:47:19 AM7/5/02
to
John wrote:
> I didn't spend very long on the alice site. I read a couple of the docs.
> I will go back again to make sure I didn't miss something.
>
> I have not been able to find source for the existing parsers in a form
> that would be understandable without spending as much time as writing it
> in the first place.
>
> I have always liked the infocom adventures and always wanted to create my
> own. I have some ideas on some things I would like to do differently.

To make this clear: Both Inform and TADS are available in source code and
both has a powerful parser included. In Inform and TADS 3 the parser is
written in the specific language, while the TADS 2 parser is coded in C.

You should keep in mind that the development of a parser is very difficult,
and even if you succeed, you haven't got more than half of the game. You
also need something like a library that controls the behaviour of the game
world and a big set of verbs (and synonyms). When you're finished with that
you start the actual game.

Now given that Inform, TADS (etc) already have all this implemented, you
should consider if it is really worth the effort to write all this code
again. Both Inform and TADS 3 are all-purpose languages that are able to do
a lot more than just IF. So maybe they will suit your purposes.

DarrenH

unread,
Jul 5, 2002, 10:42:06 AM7/5/02
to
The problem with simply writing a game in TADS or Inform is that you're
using systems that already exist. There tends to be a "sameness" about the
games that are produced, regardless of whether the program's functionality
is increased with the use of library extensions.

Sure, it's definitely easier for the creator to create games but the end
user suffers from this homogenity. For those with less of a programming
bent and more of a pure literature drive this is probably the best thing for
them.

But it's limiting. For the graphical equivalent, it would be as if all game
creators used the Space Invaders engine to produce their games, with the
caveat that they could create library files to increase the functionality to
suit their own needs. But it's still the Space Invaders engine, with all
its inherent quirks, look and feel. Nothing else, please. My machine won't
run anything on an operating system created after Windows 3.1.

Nobody can deny that the medium (the game engine) does indeed influence the
message (the game). Proprietary engines means new features being thrown out
there to test, some things that succeed brilliantly and advance the craft
and others that fail but aren't tried again.

It's obvious that there is a strong reluctance for some to try proprietary
engines, to the point of almost religious zeal (for proof, we'll see who
replies to this message and how they do it). It's in the FAQ for goodness'
sakes: "Please, please please use a specialized authoring system!" it cries.
Who does that view represent? The FAQ writer or "everybody?" Who is
"everybody?" What business is it of anyone if someone does indeed try their
own approach? All questions that I personally haven't seen satisfactory
answers to. I'm not convinced it's a PC/non-PC thing. 60% or more of the
world runs Windows as their OS. That's a bigger potential market than the
systems of the people who the current IF game engines are appeasing.

Obviously there isn't much of a commercial incentive to create game engines
from scratch anymore. And many players are also programmers, so the common
platforms make the trading of games quicker and easier for everyone. But if
someone has an idea that they wish to pursue for the love of it I'm
personally all for it.

I'm all for the spirit of ingenuity that drove Infocom, Graham Nelson and
Michael Roberts. To give them the license to see what could be done and do
it, but to deny it of anyone else is odd logic that in the long run does all
of us a disservice.

Cheers
D


"Sascha Müller" <new...@saschamueller.com> wrote in message
news:ag3m74$tvi$01$1...@news.t-online.com...

Neil Cerutti

unread,
Jul 5, 2002, 10:51:16 AM7/5/02
to
In article <2fiV8.863$f5.47482@news>, DarrenH wrote:
> The problem with simply writing a game in TADS or Inform is
> that you're using systems that already exist. There tends to
> be a "sameness" about the games that are produced, regardless
> of whether the program's functionality is increased with the
> use of library extensions.
>
> Sure, it's definitely easier for the creator to create games
> but the end user suffers from this homogenity. For those with
> less of a programming bent and more of a pure literature drive
> this is probably the best thing for them.
>
> But it's limiting. For the graphical equivalent, it would be
> as if all game creators used the Space Invaders engine to
> produce their games, with the caveat that they could create
> library files to increase the functionality to suit their own
> needs. But it's still the Space Invaders engine, with all its
> inherent quirks, look and feel. Nothing else, please. My
> machine won't run anything on an operating system created after
> Windows 3.1.

Are you claiming that, for Inform examples: Shrapnel, MST3K
Presents: "Detective", Ramses, The Space Under the Window,
Theatre, and Stiffy MacKane: The Undiscovered Country all have a
"sameness" that is worth worrying about?

Can you be more specific? What exactly is this "sameness"? How do
you define it, and how does it affect my gaming experience?

--
Neil Cerutti <cer...@trans-video.net>
*** A wandering space traveler repaid your hospitality by
leaving two bars of smithore. ***

Sascha Müller

unread,
Jul 5, 2002, 11:38:46 AM7/5/02
to
I don't think, we're talking about game engines. Inform, TADS, Hugo, etc.
are programming languages including a parser for natural languages and
libraries (that can be easily changed). Probably you wouldn't claim that we
should develop an alternative to C++ since all games made with C++ feel the
same, or something to replace OpenGL?

Maybe I don't understand what you mean with "sameness". The user interface
is customizable, it's not hardcoded (at least not in Inform). The library
can be changed, too - for example, the WorldClass library for TADS is more
powerful than the one included. What most of the IF games have in common is
a certain set of verbs and phrases that every parser understands, like
"take everything except the red skull, then unlock the door with the key,
and open it" (haven't tried this, but it's supposed to work). An
experienced player wouldn't like a game that lacks those certain phrase.

So what is left that could cause this sameness?

John

unread,
Jul 5, 2002, 12:39:38 PM7/5/02
to
(This is also a reply to Neil and Sascha's replies)

I think Darren is right. Using the systems that currently exist is great,
but all advances are going to be evolutionary rather than revolutionary. I
have some ideas that would fit somewhere inbetween. I am not as arrogant as
to say they are revolutionary yet, but I don't believe they exist right now.
I am not ready to unleash this on the world in idea form yet. You can bet
though, that once I do, this will be the first place I post.

I was under the impression that inform and TADS both use compilers to create
their adventures. The parser is not really exposed as a separate component.
At least with z-code, I could not find where the interpreting took place.
Even if I did, it would seem that it was not going to be easy to follow!!

Irrespective, I am looking more for pointers, as I think I will try to do
things differently. That is going to be the fun part for me. I am not an
author, I am a programmer. Writing the actual game holds much less interest
for me than creating some software that does what I want.

I have done investigation on a number of text adventure systems but they do
not meet my needs. I emailed the creator of TADS but unfortunately his
mailbox is full :-(

John.

"DarrenH" <jer...@overtime.ca> wrote in message
news:2fiV8.863$f5.47482@news...

OKB (not okblacke)

unread,
Jul 5, 2002, 2:07:23 PM7/5/02
to
John wrote:

> I was under the impression that inform and TADS both use
> compilers to create their adventures. The parser is not
> really exposed as a separate component. At least with
> z-code, I could not find where the interpreting took place.
> Even if I did, it would seem that it was not going to be
> easy to follow!!

I think you're using the term "interpreter" (and "interpreting") in a way that's not standard in this
community. The interpreter is just the piece of software that serves a link between the player and the
game file, serving a role similar to that of a movie projector. It's not part of the actual game. (Actually, in
TADS 2 I think the interpreter does do some parsing and stuff, but if that's not to your liking you can
easily use TADS 3 or Inform.) The parser, on the other hand, is really part of the game; it just happens
to be a part that is, in most cases, prepackaged. In Inform and TADS 3, the parser is part of the library,
in source code form, and you can modify it to your heart's content.

As for it being hard to follow -- are you really surprised? Parsing natural language -- even the
limited sort of natural language used in IF -- is no easy task.

> Irrespective, I am looking more for pointers, as I think I
> will try to do things differently. That is going to be the
> fun part for me. I am not an author, I am a programmer.
> Writing the actual game holds much less interest for me
> than creating some software that does what I want.

I think this is a worthwhile goal, and I'll be interested to see what you produce. I'd caution you,
though, to keep in mind the difference between interpreter and parser that I mentioned above, because I
think there's an expectation in this community that game authors be able to tweak the parser. If the
interpreter is distributed in binary form (as is the case with most popular existing interpreters), then the
embedded parser is inaccessible to the game author. It's conceivable that the interpreter could be
distributed in source form, but then attempts at parser modification would get tangled in the other parts
of the interpreter, and it could get messy.

--
--OKB (not okblacke)
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

L. Ross Raszewski

unread,
Jul 5, 2002, 2:18:06 PM7/5/02
to
On Fri, 05 Jul 2002 14:42:06 GMT, DarrenH <jer...@overtime.ca> wrote:
>The problem with simply writing a game in TADS or Inform is that you're
>using systems that already exist. There tends to be a "sameness" about the
>games that are produced, regardless of whether the program's functionality
>is increased with the use of library extensions.

This attitude is, in general, held predominantly by people who have
never actually looked in depth at the engines in question. Certainly,
to some extent there is truth in it, but nothing on the scale of what
the "I wanna write my own java parser" camp believes.


>
>Sure, it's definitely easier for the creator to create games but the end
>user suffers from this homogenity. For those with less of a programming
>bent and more of a pure literature drive this is probably the best thing for
>them.

No, it's pretty much the best thing for everyone. NLP is *hard*. Not
"I'm a programmer so I can do it , but you're a writer so you can't"
hard, but "I'm a PhD who specialized in NLP, and *I* can barely do it"
hard.


>
>But it's limiting. For the graphical equivalent, it would be as if all game
>creators used the Space Invaders engine to produce their games, with the
>caveat that they could create library files to increase the functionality to
>suit their own needs. But it's still the Space Invaders engine, with all
>its inherent quirks, look and feel. Nothing else, please. My machine won't
>run anything on an operating system created after Windows 3.1.

THere's a subtle thing here: your choice of engine for example is
intentionally picked to make the claim thast IF engines are clunky and
outdated. This is only true insofar as any textual interface is
"outdated"; thee *isn't* any "up" for one to go in terms of a useful
parser interface -- people *don't* want to speak in plain english to
the game, which is just as well because that's intractable.

>
>Nobody can deny that the medium (the game engine) does indeed influence the
>message (the game). Proprietary engines means new features being thrown out
>there to test, some things that succeed brilliantly and advance the craft
>and others that fail but aren't tried again.
>

The first sentence of this is true. THe rest of this paragraph, I
don't quite understand.

>It's obvious that there is a strong reluctance for some to try proprietary
>engines, to the point of almost religious zeal (for proof, we'll see who
>replies to this message and how they do it). It's in the FAQ for goodness'
>sakes: "Please, please please use a specialized authoring system!" it cries.
>Who does that view represent? The FAQ writer or "everybody?" Who is
>"everybody?" What business is it of anyone if someone does indeed try their

"Everybody", as defined by "everybody who's tried playing a game using
a homebrew engine" -- Every *single* -- each and every one -- game in
the past, say, ten years, that's used a homebrew engine has been far
more cripled and limited in its understanding than even the worst
inform or tads game.

>own approach? All questions that I personally haven't seen satisfactory
>answers to. I'm not convinced it's a PC/non-PC thing. 60% or more of the
>world runs Windows as their OS. That's a bigger potential market than the
>systems of the people who the current IF game engines are appeasing.
>

IF has *no* real commerical viability. We have established this through
repeated testing. The IF community is not the world at large. I find
it hard to believe as well, but every poll we've ever done shows that
windows users make up only a little more than a third of the IF
community at large.

>Obviously there isn't much of a commercial incentive to create game engines
>from scratch anymore. And many players are also programmers, so the common
>platforms make the trading of games quicker and easier for everyone. But if
>someone has an idea that they wish to pursue for the love of it I'm
>personally all for it.
>

SO are we all. But most people who want to sdo a homebrew engine
aren't lookign to "strike out in a new direction" or introduce a new
paradigm in IF parsing. THey have total misconceptions of the
abilitieis of extant systems and just want to write a game.

UI know lots of people think that variety for its own sake is a Good
Thing, but frankly, there is very little new ground to cover in the
parser area. It is a waste of effort to invent your own parser if, as
is *almost certainly the case*, the extant parsers will do the job for
you. The wheel has already been invented. There really is no benefit
in anyone inventing it again.

L. Ross Raszewski

unread,
Jul 5, 2002, 2:24:45 PM7/5/02
to
On Fri, 05 Jul 2002 16:39:38 GMT, John <nojgoa...@hotmail.com> wrote:
>
>I was under the impression that inform and TADS both use compilers to create
>their adventures. The parser is not really exposed as a separate component.
>At least with z-code, I could not find where the interpreting took place.
>Even if I did, it would seem that it was not going to be easy to follow!!

As opposed to generating the adventures ex nihilo via magic, yes.

In TADS 2, the parser is part of the TADS interpreter. In inform, the
parser is a block of Inform code contained in the file 'parser.h'

>
>Irrespective, I am looking more for pointers, as I think I will try to do
>things differently. That is going to be the fun part for me. I am not an
>author, I am a programmer. Writing the actual game holds much less interest
>for me than creating some software that does what I want.
>

Ah, well then, it sounds like you want to writer an engine and not a
game. Have fun.
But be warned: almost no one does this successfully. The overwhemling
majority of game engines produced (That is, both authoring systems and
games with homebrew engines) suck amazingly.

THe *reason* there are only 3 major IF languages around here isn't
becasuse we've somehow prevented people from writing their own --
there are *dozens* of other engines that have been written. But all
the other ones are *lousy*.

>I have done investigation on a number of text adventure systems but they do
>not meet my needs. I emailed the creator of TADS but unfortunately his
>mailbox is full :-(
>

Could you share with us the needs that are not met? We have found time
and time again that people who make this claim make it on the basis of
an incomplete knowledge of the abilities of the extant authoring
systems. (Perhaps my thinking is too constrained by the paradigm, but
I can't even *imagine* anything worthwhile to do in a text adventure
system that is flat out impossible in one of the existing languages.)

Kevin Forchione

unread,
Jul 5, 2002, 2:52:58 PM7/5/02
to
"DarrenH" <jer...@overtime.ca> wrote in message
news:2fiV8.863$f5.47482@news...
> The problem with simply writing a game in TADS or Inform is that you're
> using systems that already exist. There tends to be a "sameness" about
the
> games that are produced, regardless of whether the program's functionality
> is increased with the use of library extensions.

One could arguably say that that a certain degree of "sameness" is a
necessary prerequisite of any art form.

But, let's grant that the engines are not equipped to handle what you want
to do with them. Given that it's possible to scrap the entire library for
Inform or TADS 3, what is it about what you want to do that makes the
languages themselves unacceptable?

I ask this, because these both Inform and TADS 3 game files can be run on
any interpreter that understands the game file layout, and the particulars
of the library are irrelevant. However, the languages themselves, apart from
their libraries, are considered very good for the writing of IF.

Is this not the case for you?

> Sure, it's definitely easier for the creator to create games but the end
> user suffers from this homogenity. For those with less of a programming
> bent and more of a pure literature drive this is probably the best thing
for
> them.
>
> But it's limiting. For the graphical equivalent, it would be as if all
game
> creators used the Space Invaders engine to produce their games, with the
> caveat that they could create library files to increase the functionality
to
> suit their own needs. But it's still the Space Invaders engine, with all
> its inherent quirks, look and feel. Nothing else, please. My machine
won't
> run anything on an operating system created after Windows 3.1.

Ah... now we're getting to it. But if I may point out, as they say in the
industry, you're talking about the presentation layer, and those particular
engines have been running on pre-windows 3.1 OSes as well.

> Nobody can deny that the medium (the game engine) does indeed influence
the
> message (the game). Proprietary engines means new features being thrown
out
> there to test, some things that succeed brilliantly and advance the craft
> and others that fail but aren't tried again.
>
> It's obvious that there is a strong reluctance for some to try proprietary
> engines, to the point of almost religious zeal (for proof, we'll see who
> replies to this message and how they do it). It's in the FAQ for
goodness'
> sakes: "Please, please please use a specialized authoring system!" it
cries.
> Who does that view represent? The FAQ writer or "everybody?" Who is
> "everybody?" What business is it of anyone if someone does indeed try
their
> own approach? All questions that I personally haven't seen satisfactory
> answers to. I'm not convinced it's a PC/non-PC thing. 60% or more of the
> world runs Windows as their OS. That's a bigger potential market than the
> systems of the people who the current IF game engines are appeasing.

Well, we won't go into side issues. The IF-archive is littered with scores
of development systems that span the gammut of OSes and presentation layers.
And there've been parsers written in BASIC, C, C++, as well as proprietary
software. Some of them are more sophistcated than others, some of them even
approaching the golden Infocom standard.

But what I am interested in is what world model you have in mind that is so
very different from these others that it makes them unsuitable.

> Obviously there isn't much of a commercial incentive to create game
engines
> from scratch anymore.

It wasn't commercial interest that drove Graham Nelson to create Inform. Nor
did they drive the TADS 3 development. No one here should discourage you
from pursuing a new design from purely commercial reasons!

>And many players are also programmers, so the common
> platforms make the trading of games quicker and easier for everyone.

Agreed.

>But if
> someone has an idea that they wish to pursue for the love of it I'm
> personally all for it.

Agreed.

> I'm all for the spirit of ingenuity that drove Infocom, Graham Nelson and
> Michael Roberts. To give them the license to see what could be done and
do
> it, but to deny it of anyone else is odd logic that in the long run does
all
> of us a disservice.

I don't think this is the case. If someone came asking advice on parser
development in the Infocom style, I don't think anyone would say, "toss out
all the old systems, and figure it out yourself." They would say, "Have you
looked into foo and baz?" And then when you respond, "Yes, but they produce
much of a sameness." They would respond, "Well, what is it you want to do
differently?"

Once that last question is answered, those with system experience can better
assess whether the particular system can be adapted to do what you want, or
whether you're better off developing a new one from the ground up.

So, tell us ... what do you have in mind?

--Kevin

OKB (not okblacke)

unread,
Jul 5, 2002, 3:38:33 PM7/5/02
to
L. Ross Raszewski wrote:

> THe *reason* there are only 3 major IF languages around
> here isn't becasuse we've somehow prevented people from
> writing their own -- there are *dozens* of other engines
> that have been written. But all the other ones are *lousy*.

I think that's a harsh and inaccurate statement. Many of the non-big-three languages are designed
to offer a less programming-intensive route to writing IF, and willingly sacrifice some power for that.
That doesn't mean they're lousy.

NSF

unread,
Jul 5, 2002, 3:37:19 PM7/5/02
to
"John" <nojgoa...@hotmail.com> wrote in message news:<ts1V8.1521$x6....@newsread1.prod.itd.earthlink.net>...

> All,
>
> I am interested in writing my own text adventure. I have done some research
> including looking at various text adventure creation systems, but not found
> the information I am looking for.
>
> I would like to create the piece that understands what the user is
> requesting and that maps that to nouns, verbs etc. Basically the
> interpreter. For various reasons I would like to do this in Java. I have
> the programming skills, just not the natural language processing skills.


I'm interested in this too, but for a different reason. I want to
create adaptive NPC. Anyway, here are some links:

http://www.ling.gu.se/~nivre/kurser/wwwstat/ --Online Course in
Statistical NLP

http://fieldmethods.net/ --An NLP weblog

http://www-2.cs.cmu.edu/~ralf/nlp.html --Collection of web based NLP
resources

NSF

unread,
Jul 5, 2002, 4:08:56 PM7/5/02
to
Since I'm posting through Google I can't edit my earlier post, it
hasn't even made it to the group, but here are a few more resources:

I strongly suggest reading the FAQs on these groups before posting.

alt.usage.english English grammar, word usages, and related
topics.
comp.ai.nat-lang Natural language processing by computers.
comp.ai.nlang-know-rep Natural Language and Knowledge
Representation.
(Moderated)
comp.speech Research & applications in speech science &
technology.
sci.lang Natural languages, communication, etc.
alt.etext Electronic texts.
comp.text.sgml ISO 8879 SGML structured documents markup
languages
comp.theory.info-retrieval Information Retrieval topics. (Moderated)
comp.ai.doc-analysis.misc General document understanding technologies
comp.internet.library Discussing electronic libraries.
(Moderated)

Enjoy

Gregory W. Kulczycki

unread,
Jul 5, 2002, 4:20:01 PM7/5/02
to
John,

If you want to write a parser in Java, I would suggest looking at ANTLR.
I am using it for a compiler project and have often toyed with the idea
of writing an IF parser with it.

I would also suggest you formulate your ideas about what new and
different things you would like to accompish and suggest them to people
in this news group. Because:

(1) There are a lot of smart people lurking on this news group and for such
a large project you may need all the good suggestions you can get.

(2) It is very unlikely that anyone would try to take your ideas and beat
you to the punch. Very few people are interested in writing parsers and
those that do would probably want to do it THEIR own way rather than
yours.

(3) If you post your ideas to this group at least they are on record
in the archives and nobody can say they thought of them first.

Finally, you might even think about rewriting or modifying the INFORM
parser or the TADS3 parser since neither of them are built-in to the
language.

Whatever you decide, try to think about how other people will use it. It
would be helpful if your system was at least as easy to use or modify as
INFORM or TADS.

Good luck.
G. Kulczycki

John

unread,
Jul 5, 2002, 5:14:49 PM7/5/02
to
Thankyou for both of your posts!!

John.

"NSF" <sillyq...@mail.com> wrote in message
news:6d245961.02070...@posting.google.com...

John

unread,
Jul 5, 2002, 5:22:02 PM7/5/02
to
BIG SNIP!

> So, tell us ... what do you have in mind?
>
> --Kevin

My reticence on telling everyone what my idea is, is not for financial
reasons, nor is it because someone might steal my idea (although that would
suck!!!). The reason is that I don't want people to put it down before I
have had chance to investigate it more.

That said, one of the major parts of what I am trying to do is create new
objects dynamically. For instance, the user can create a hammer and then
use that hammer to do things.

Now, I know that I have opened a can of worms here. Without more context
this is going to be hard to justify. Take my word for it at this point that
this is a good idea. What I am trying to show is that there is something
that these systems do not enable you to do. If there is a system that
allows this, I would be interested in seeing it.

John.

Daniel

unread,
Jul 5, 2002, 5:46:43 PM7/5/02
to
On Fri, 05 Jul 2002 21:22:02 GMT, "John" <nojgoa...@hotmail.com>
wrote:


<snip>


>That said, one of the major parts of what I am trying to do is create new
>objects dynamically. For instance, the user can create a hammer and then
>use that hammer to do things.

TADS 2 (and I assume TADS 3 as well though I haven't gone near that
one yet) can already do this. Take a look here:
http://tela.bc.ca/tads-manual/tads-8.html
and scroll down to the section labeled "Dynamic Object Creation"

>Now, I know that I have opened a can of worms here. Without more context
>this is going to be hard to justify. Take my word for it at this point that
>this is a good idea. What I am trying to show is that there is something
>that these systems do not enable you to do. If there is a system that
>allows this, I would be interested in seeing it.

Seems like a perfectly reasonable thing to want to do to me. A box of
toothpicks, matches, napkins....and I'm sure a hundred other things
are helped by dynamically created objects. I suppose you could even
make a star trek style replicator, though it would be a bloody mess
to work the bugs out.

John Colagioia

unread,
Jul 5, 2002, 5:47:14 PM7/5/02
to
"John" <nojgoa...@hotmail.com> wrote:
>I guess what I need is a way to determine the nouns, verbs, etc. from a
>sentence. From then I can pretty much deal with the input. Is this what
>the infocom adventures did? Or was it purely a matching of the game
>definition text with the user input?

The Infocom games included a specialized "quasi-parser."
Basically, it tried to match user input to a pre-existing
table of grammar, starting with the text of the verb.

>Again, any pointers very appreciated.

For Infocom-style parsing, you probably won't do much
better than looking at the Inform standard library; you
can find the latest version at:

http://www.ifarchive.org/indexes/if-archiveXinfocomXcompilersXinform6Xlibrary.html

Inform targets the same virtual machine as Infocom did
and makes a good attempt at replicating most of the
"look and feel" of the games.

The problem, of course, is that the library is written
in fairly "heavy" Inform, at some spots. However:

- Grammar.H will give you a pretty good idea of how the
grammars were defined.
- English.H will illustrate the kinds of error messages
that are often needed.
- ParserM.H, particularly the Parser__Parse() function,
is the actual guts of the parsing mechanism which,
despite its bulk, is somewhat disappointing, considering
how effective it seems.

The word "seems" is sort of a key. You don't actually
have to understand anything outside of your limited
vocabulary, as long as you can fake it...

In the case of Infocom, Inform, TADS, and the other IF
systems, it really boils down to a combination of top-
down and bottom-up parsing techniques, and is therefore
little more sophisticated than your average compiler.

Does that help? Or does it just muddy the issue?

Closer to the subject of "real" NLP, back in high
school, my senior-year English teacher ran us through
a few exercises to discuss grammar from a morphology
standpoint, rather than a set of recursive definitions;
things like "an adverb precedes an adjective or is
directly before or after a verb; it frequently ends in
'-ly.'" That sort of thing might be up your alley.
Alas, I don't have a better reference than that vague
description, but perhaps someone more well-read in
such fields might.

DarrenH

unread,
Jul 5, 2002, 5:47:25 PM7/5/02
to
Hi Neil,
I obviously can't claim to speak about your gaming experience. I should
precede all statements of a subjective nature with "I think" henceforth.
Also, all comments here refer to Inform games.

If I were to imagine myself dropped into a simulated-environment type of
game, essentially blindfolded but all necessary detail being dictated to me
by someone beside me, I think one of the first questions I would ask is
"where the heck am I". Simple enough I think. One of the most basic things
I can imagine asking when I'm lost and (usually) amnesic.

The problem is, nobody thinks to include the ability for the game to
understand that simple question: Where am I.

So as a test I loaded up five games: Curses, Spider and Web, Shrapnel,
Theatre, and The Space Under the Window (I haven't played all of these but
I'll submit that they're likely all excellent games. My comments are not
meant as criticism of the games themselves but to the envelope they're
delivered in).

Here's the responses I received to the question "Where am I":

Curses--That's not a verb I recognize.
Spider and Web--That's not a verb I recognize.
Shrapnel--That's not a verb I recognize.
Theatre--That's not a verb I recognize.
The Space Under the Window--Currently there is no "where am I" near the
narrative (all illegal entries are treated with this response)

What is my point? That I should have used the word "look" to find out where
I am.

I should have known that, shouldn't I? But why?

The reason I should have used the word "look" is because that's the way
games have always done it. Had the programmers felt a need to code up a
WhereIs [Noun] verb, a simple verb/noun grammar, it would have fixed the
problem. But it's not worth it, because they know we'll use the word
"look".

Multiply this assumption by all of the assumptions we walk into a game
carrying (Floyd, bring me the ladder) and you've got a gaming interface that
hasn't really progressed beyond Hitchhiker's Guide to the Galaxy in a real
sense. We're unwittingly allowing ourselves to fall into a pattern of
coding that hasn't changed in years.

We're allowing the envelope, the gaming platform, to make design decisions
for us.

The very fact that some of the games I mentioned are truly great examples of
IF that stand up to anything Infocom ever issued is proof that, while the
ability to extend the capabilities of the platforms is there, not much in
the end actually gets done. In defense of current Inform/TADS coders, it's
often hard enough to just get the story file to work properly, forget having
to code a new parsing/object handling/etc. engine from scratch.

But that isn't the same as innovating the design of the envelope itself,
despite what can already be done 'under the hood'. The only course to
progress (and maybe even a new market) is to adapt, rework, and throw out
ideas. And maybe keeping the code proprietary. Perhaps. Either way, if
you want to try building the proverbial better mousetrap, you sometimes
don't work on the old one. I submit that you look at why it sucks (it kills
mice...I don't like killing mice) and what you can do to improve it (how
about the bait in a container that closes, trapping the mouse for humane
removal later?).

There's a huge role for the current players, that need not be said. What we
need is some innovation, and more importantly some encouragement given those
who wish to take a stab at creating their own system. We as IF fans depend
on new standards being created, not adherence to older standards simply
because it's easier that way.

Cheers
D

Alex Warren

unread,
Jul 5, 2002, 6:50:30 PM7/5/02
to
John wrote:

> That said, one of the major parts of what I am trying to do is create new
> objects dynamically. For instance, the user can create a hammer and then
> use that hammer to do things.

As Daniel Freas says, TADS can do it, and so does Quest. You can create objects
on-the-fly, and because Quest's objects can have properties and script commands
associated with them, you could fairly easily let the user create a hammer. With
a bit of thought, say by making the hammer be of an object type that you can hit
things with, other objects and NPC's (actually also set up just as objects in
Quest) could then react naturally to it when you hit them.


Alex Warren
http://www.axeuk.com/quest/

Daniel Barkalow

unread,
Jul 5, 2002, 7:14:48 PM7/5/02
to
On Thu, 4 Jul 2002, John wrote:

> I would like to create the piece that understands what the user is
> requesting and that maps that to nouns, verbs etc. Basically the
> interpreter. For various reasons I would like to do this in Java. I have
> the programming skills, just not the natural language processing skills.

Java is a terrible language for writing interactive fiction
in. Interactive fiction primarily consists of singleton objects, which are
very verbose in Java (to the extent that they're possible). So you should
at least plan to have your games written in some other language and
interpreted by the Java program. You might want to think about using
Python or a LISP variant, since these allow you to do a lot of constant
data. Realize that you're going to be essentially writing a lot of
complicated formatted text (in addition to some code). You might want to
look at PAWS, which is in Python.

> It would seem that this has been done a number of times with each of the
> systems. The problem I have found though is that this code is not visible.
> People create these scripts and the builder takes those and creates a
> mechanism to parse the users input.

The various systems combine the parsing algorithm (from the provided
code) with the list of nouns and verbs added by the particular game.

> I would appreciate any pointers to either opensource projects or other
> information in this area. Also if there are good natural language
> processing books geared to text adventures I would also be interested.
> Also, if there is a better place to ask this question please let me know.

Parsing for IF isn't really like actual natural language parsing. People
playing text adventures are essentially speaking in imperative
headlines: "GET PAPER. MAKE HOLE IN ONE. DROP OFF SHELF. READ ALL ABOUT
IT." The issues are very different from trying to parse prose, because
some things are ambiguous in headlines but sentence complexity is very
limited and there are only a few possible constructions.

(Hmm... IF in postscript? TeX? Such bad ideas, but since I started IF
playing Adventure on a paper terminal, sort of tempting...)

-Iabervon
*This .sig unintentionally changed*

Mike Roberts

unread,
Jul 5, 2002, 7:39:23 PM7/5/02
to
"DarrenH" <jer...@overtime.ca> wrote:
> The reason I should have used the word "look" is because
> that's the way games have always done it.

You're conflating two different things here. First, there's the question of
why the authors chose to use "look" as the command. Second, there's the
matter of how the player is supposed to know this. They're different
things, even though there's a relation between them.

As for why the authors chose "look," I can't speak for them, but I can
speculate that it's for the same reasons that menus tend to be in the same
places in Windows programs, and the steering wheels and brake pedals and
other main controls in cars tend to have similar layouts: experienced users
benefit from consistent use of conventions across a class of related user
interfaces. Furthermore, most such widespread conventions (in IF and
elsewhere) have stood the test of time and been refined by long use, so far
from being historical straitjackets for the unimaginative, they're proven
solutions to non-trivial problems.

> We're allowing the envelope, the gaming platform, to make
> design decisions for us.

I disagree; I would say instead that we're deliberately deciding to conform
to conventions where there's no advantage in deviating from them.

As for the second issue - how the player is supposed to know to type
"look" - your claim that it's because it's "the way games have always done
it" is partially correct: it's correct in that, if you're an experienced
player, you would reasonably expect a new game to conform to this
well-established convention. I disagree, however, with your implication
that this is somehow unfair to inexperienced players because they're not
familiar with the conventions of the genre. The text parser is a user
interface, not an artificial person; any suggestion to the contrary is
what's unfair to inexperienced players, because no matter how many
variations of "look" the parser understands, it's never going to understand
more than a tiny fraction of the range of possibilities that a human English
speaker could reasonably be expected to recognize. The only thing that's
fair to an inexperienced player is to provide a set of instructions on
operating the unfamiliar user interface; having done this, we can reasonably
expect the player to type "look" - not because the player has to know it's
the way it's always been done, but simply because we've told them to type
"look."

> We're unwittingly allowing ourselves to fall into a pattern
> of coding that hasn't changed in years.

I think a little perusal of archived raif articles will show that people
around here give a lot of thought to design issues at every level; it's
simply not accurate to say that the community is unable to see beyond the
narrow confines of convention.

--Mike
mjr underscore at hotmail dot com

OKB (not okblacke)

unread,
Jul 5, 2002, 7:43:52 PM7/5/02
to
John wrote:

> That said, one of the major parts of what I am trying to do
> is create new objects dynamically. For instance, the user
> can create a hammer and then use that hammer to do things.

As others have mentioned, dynamic object creation is indeed theoretically possible with existing IF
languages. The example you gave, though, makes me think that what you're interested in attempting is a
more full-featured kind of thing. Dynamic object creation (at least in Inform) tends to be used for large
numbers of identical objects, rather than for unique objects. Your example seems to be pointing toward a
more simulationist model, where objects in the game world can be combined in rule-based ways -- an
intriguing concept.

I'm interested, though, in your reasons for believing that existing IF languages block you at the
language level from achieving this goal. It seems to me that, as long as the language being used provides
some moderately useful kind of dynamic object creation, it should suffice. The real trick is devising a
mechanism for defining how the user creates a hammer, what things he can do with the hammer he
creates, etc. -- and, to me, this seems like the domain of the library.

So, what is it about the existing IF languages that you think would prevent you from doing this?
(I'm not saying it's definitely possible in an existing language -- I've never attempted such a complex
project, and who knows what problems you might encounter -- but I don't see any obvious reasons why it
shouldn't be.)

John

unread,
Jul 5, 2002, 7:59:45 PM7/5/02
to
Thankyou, very helpful. I will look at those files.

> "an adverb precedes an adjective or is
> directly before or after a verb; it frequently ends in
> '-ly.'"

That is where I was initially leaning. I asked a question on sci.lang
recently with that in mind.

John.

"John Colagioia" <JCola...@csi.com> wrote in message
news:3d26...@excalibur.gbmtech.net...

John

unread,
Jul 5, 2002, 8:13:23 PM7/5/02
to
So I have to admit that I didn't realize that dynamic object creation was
possible with the existing tools. I have looked at the various packages,
but not in depth, and some much more than others.

As I said in a different post, the allure for me as a programmer is to
create something. Using someone elses package is not where the attraction
is. I want to learn more about NLP and also create a game. I gravitate
towards the games I likes as a kid. Infocom was one of my favorites with
the dry sense of humor.

I will report back in a couple of weeks with my progress. I want to try
some prototypes first as this really is just a very sketchy idea at this
point.

My hope is that whatever I create, it will be different. Whether it will be
good is up to the people that use it. If nothing else it will be a starting
point for other people to write their own adventures and potentially bring
back a revival? I can hope!!!

John.

"OKB (not okblacke)" <Bren...@aol.com> wrote in message
news:Xns9242A8...@12.252.202.62...

Kevin Forchione

unread,
Jul 5, 2002, 8:23:16 PM7/5/02
to
"John" <nojgoa...@hotmail.com> wrote in message news:_5oV8.1812

> My reticence on telling everyone what my idea is, is not for financial
> reasons, nor is it because someone might steal my idea (although that
would
> suck!!!). The reason is that I don't want people to put it down before I
> have had chance to investigate it more.

Fair enough.

> That said, one of the major parts of what I am trying to do is create new
> objects dynamically. For instance, the user can create a hammer and then
> use that hammer to do things.

Hmmm. I thought you were interested in an Infocom style parser. This is
another issue altogether - and an interesting one, I might add.

> Now, I know that I have opened a can of worms here. Without more context
> this is going to be hard to justify. Take my word for it at this point
that
> this is a good idea. What I am trying to show is that there is something
> that these systems do not enable you to do. If there is a system that
> allows this, I would be interested in seeing it.

In terms of the class / object model, yes, that is probably true. A
dynamically created object reflects the class that it was instantiated from.
The systems do not, for instance, let you create an object from a class or
object that isn't already pre-defined, so to speak.

One of the little puzzles I've been bouncing around in my head goes
something like this: There's a machine with a slot on the top, and a slot on
the bottom. Drop in random game objects into the top, and presto, out pops a
composite object that inherits traits from the other objects, in the order
that they were placed into the machine. In other words, states and behaviors
would be encoded into the new object.

TADS can't do this kind of thing, per se, because classes can't be
dynamically composed at runtime. In fact, neither can Java or C++. But TADS
3 *can* have a simple class derived from the object base class, and using
propNotDefined() *can* redirect any property callls directed to the object
to dynamically-created objects that serve as delegates for the call.

Now, if TADS 3 can do that, then suppose the next scenario - an object that
assumes the form of anything it comes into contact with. Take an object such
as a the mnemonic polyalloy of T2. Anything the object "comes into contact
with" it assumes the states and behaviors of. Our mnemonic polyalloy comes
into contact with a chair, and now the PC can sit in it. The alloy comes
into contact with a book, and suddenly the object is an exact clone of the
book. The object comes into contact with the PC, and you've got twins.

One step further. An object that learns. In this case the object adjusts the
choice of behaviors based on the outcome of the action. A command such as
<<break glass with mnemonic polyalloy>> has little effect if the object is
virgin new, but if the object has come in contact with a rock or hammer -
the effect is more drammatic. Granted this option is more difficult than the
other two because somehow we must determine what the "best" outcome for a
given situation should be.

Of these examples, the first couple are easy enough to do in TADS 3, once
you create a class that allows it to be recognized by the parser and the
model world containment/sense-passing systems. The complexity then comes
into play in handling the delegation. First-come-first-serve simplifies the
model, but its a programmatic issue that can be played with.

Inform can do something similar to this - I believe - by simply assigning
attributes to an object, but because all actions are routed through before()
and after() routines, something like the above using delegation objects can
probably be done.

What can't be done with these systems is to dynamically introduce an object
into the game during runtime. Say we have a hammer object module that we
want to *pop* into our game at some point - an object that's not part of the
original game compilation. Can't be done with these systems. Furthermore, an
object introduced into the game like that would require a very simulationist
library, and a model world based on attributes and interfaces that wouldn't
need to evaluate a given class or object.

--Kevin


John

unread,
Jul 5, 2002, 8:36:54 PM7/5/02
to
> What can't be done with these systems is to dynamically introduce an
object
> into the game during runtime.

Thats what I want! Thats what I am going to try to do. There is a subtle
shift that I think will make this work, but given that I have never created
a text adventure, only played them, I need to try a few things to see if I
can make it work.

John.

"Kevin Forchione" <ke...@lysseus.com> wrote in message
news:ULqV8.1411$St6.15...@newssvr13.news.prodigy.com...

Mike Roberts

unread,
Jul 5, 2002, 8:55:35 PM7/5/02
to
"John" <nojgoa...@hotmail.com> wrote:
> > What can't be done with these systems is to
> > dynamically introduce an object into the game
> > during runtime.
>
> Thats what I want! Thats what I am going to
> try to do.

Let me clarify what Kevin means here: you can't introduce a new *class* at
run-time. You can dynamically create as many instances of existing classes
as you want - if you're talking about creating objects based on code that's
already compiled into the game, then you're fine. If you're talking about
having the player type in some new Java code into a text editor and then
importing that into a running game, no, tads can't do that directly (you
could, though, write your own Java compiler and VM in tads itself, and then
import and run the Java - but that tads doesn't have a built-in way of doing
this).

--Mike

Adam Thornton

unread,
Jul 6, 2002, 1:34:13 AM7/6/02
to
In article <rdrV8.26$n62...@news.oracle.com>,

Mike Roberts <mjr-S...@hotmail.com> wrote:
>tads can't do that directly (you
>could, though, write your own Java compiler and VM in tads itself, and then
>import and run the Java - but that tads doesn't have a built-in way of doing
>this).

PITTSBURGH: APRIL 1 2003

Andrew Plotkin today released his T3-abuse, "Introspection." On first
glance, it appears to be a straightforward narrative of a camping trip
with a genie in the Old Country, in a strange countryside of sand,
windows, and attics.

However, when the protagonist finally accedes to the genie's incessant
demand to rub his lamp, the player is catapulted into a nightmarish
netherworld of developing Java-based "business logic" to support a
terrifying database-backed three-tiered version of "Hunt the Wumpus," as
the genie metamorphoses into the cruel and inhumane villian, Mr. Bunny.

The Java compiler is written in TADS3; the bytecode interpreter is
implemented in Glulx, which has in turn been implemented atop TADS3.
When asked to comment, Plotkin merely smirked and said, "It's
deliberate."

No reviewers were available for comment, as their heads had all imploded.

John Colagioia

unread,
Jul 6, 2002, 9:48:21 AM7/6/02
to
"DarrenH" <jer...@overtime.ca> wrote:
[...]

>If I were to imagine myself dropped into a simulated-environment type of
>game, essentially blindfolded but all necessary detail being dictated to me
>by someone beside me, I think one of the first questions I would ask is
>"where the heck am I". Simple enough I think. One of the most basic things
>I can imagine asking when I'm lost and (usually) amnesic.

This may be a stupid question, but why does everyone keep
referring to starting the game with amnesia? In my
(admittedly possibly limited) experience, the better games
tend to (a) come with background material to read, (b)
quickly establish or at least sketch the background in the
opening text, or (c) make this a key point of the story.

I suspect that if you keep having the feeling that you
don't know what's going on, you're either playing less-
complete games, or you're not reading the material.

>The problem is, nobody thinks to include the ability for the game to
>understand that simple question: Where am I.
>So as a test I loaded up five games: Curses, Spider and Web, Shrapnel,
>Theatre, and The Space Under the Window (I haven't played all of these but
>I'll submit that they're likely all excellent games. My comments are not
>meant as criticism of the games themselves but to the envelope they're
>delivered in).
>Here's the responses I received to the question "Where am I":

Question: Was the opening text of these, including the
description of the starting locale, insufficient
information for you to figure this out? I get "Attic (in
Meldrew Hall)" in "Curses," and "End of Alley" in "Spider
and Web"--both with fairly complete descriptions.

Responding to the on-screen description of that location
with "Where am I" seems a less like you're playing the
game you've loaded and more like you're trying to
contrive evidence, to be honest.

[...]


>What is my point? That I should have used the word "look" to find out where
>I am.
>I should have known that, shouldn't I? But why?
>The reason I should have used the word "look" is because that's the way
>games have always done it.

In particular, most of the games mentioned come from the
Infocom standard; the instructions of those games described
the use of "look."

I'll grant you that it is unfair for most games to not come
with similar documentation. I'd give Curses more leeway on
that point, though, seeing as how, when it was written, it
would have been unlikely that an Infocom non-fan would've
picked it up...

Although, on that note, I miss "look around" as a verb.

>Had the programmers felt a need to code up a
>WhereIs [Noun] verb, a simple verb/noun grammar, it would have fixed the
>problem. But it's not worth it, because they know we'll use the word
>"look".

Yes. And most programs on the Macintosh follow the same UI
guidelines, because those that don't are unusable to those
who have Mac experience; same with just about every
platform.

See IBM's RealPhone and RealCD (Windows programs, in this
case) for why this is generally a truism.

>Multiply this assumption by all of the assumptions we walk into a game
>carrying (Floyd, bring me the ladder) and you've got a gaming interface that
>hasn't really progressed beyond Hitchhiker's Guide to the Galaxy in a real
>sense. We're unwittingly allowing ourselves to fall into a pattern of
>coding that hasn't changed in years.

I'm fairly sure it's not unwitting; at least, not for all
programmers. In the case of many of the games you mention,
it was (presumably) a considered decision to mimic the
"look and feel" of Infocom's line.

>We're allowing the envelope, the gaming platform, to make design decisions
>for us.

To be blunt, that's the job of a tool. It makes your life
easier, partly because it constrains your choices. That
is, it multiplies your power (be it physical or mental) by
forcing you to focus your energies.

[...]


>But that isn't the same as innovating the design of the envelope itself,
>despite what can already be done 'under the hood'. The only course to
>progress (and maybe even a new market) is to adapt, rework, and throw out
>ideas.

Or, ask things like "how can this particular thing be done
in existing systems?" I have yet to find, after five years
of tinkering (which may soon result in an actual game),
anything that (a) can't be done in Inform which (b) can be
done at all easily in another language, IF or not.

I see how to do sense-passing, though I haven't actually
tried it. I have most of the parts (I believe) of an NPC
that'll act on his own volition (though not yet in
"interesting" ways). I have some fairly simulation-heavy
objects (like the old "I need a knife, but I don't have a
knife, so I'll break something fragile and use a shard"
kind of thing), though they need major, major debugging
before being let out into the wild. None of these are
constrained by the platform--no more than they're
constrained by needing to run on a modern-type CPU after
being compiled.

I think that sounds discouraging. It shouldn't. If you
or anyone else *wants* to build their own system from
scratch, have a ball with it. It's an entertaining
activity (having written a handful of compilers,
interpreters, and virtual machines, myself, I speak from
direct experience), and occasionally, though pretty
rarely, proves useful.

However, three caveats:

1. It's always more work than it seems. Much more.

I'm not even talking about debugging. I'm talking about
research into the current state of the art (to make sure
you're actually doing something new), design, and actual
development.

2. Your energies would probably be more appreciated in
raising the existing technology to your standards,
rather than bashing the "establishment" in favor of
your own, not-yet-existing system.

Doing this leads to the existing community feeling that
it's under another pointless attack (any community is
like this), and some will try to defend themselves,
leading to the annoying, "mad-scientist-esque"
persecution complexes that some people around here seem
to have.

3. Unless the resulting system is provably better in
many respects, don't expect anyone to flock to your
banner. In many ways, an "almost perfect" system
can seem like a greater failure than a sparse proof
of concept.

I can think of at least five "new systems" off the top
of my head which started with the best of intentions,
but shot themselves in the foot by failing to do one
or more of the following:

- Materialize. As I said, it's hard.
- Maintain most of the advantages of existing systems,
including error recovery ("That's not a verb I
recognize") and portability.
- Create a standard library, so programmers needn't
write their own "take" verb, for example.
- Be extensible, so programmers *can* write their
own "rant" verb, if they need it.
- Succeed in its original goal. A system that's
"just like TADS," but with one new feature that
doesn't actually work, isn't compelling.

A "good" system also needs (as I think has been said
many times, around here) a good game to show it off,
spurring the imagination of potential users, and
makes sure there aren't any glaring omissions in the
system.

Would any of the existing system designers like to
tell me that I'm talking through my...uhm...hat? I'd
*love* to hear that this stuff is much easier than
I'm making it out to be. I hate being the cynical
one...

[...]

OK, I've (yet again) ranted *more* than enough.
Hopefully, there's something useful, or at least
interesting, to someone, somewhere in this mess...

Neil Cerutti

unread,
Jul 6, 2002, 11:06:06 AM7/6/02
to
On Fri, 05 Jul 2002 21:47:25 GMT in <NtoV8.900$f5.49200@news>,
DarrenH wrote:
> Hi Neil,
> I obviously can't claim to speak about your gaming experience.
> I should precede all statements of a subjective nature with "I
> think" henceforth. Also, all comments here refer to Inform
> games.
>
> If I were to imagine myself dropped into a
> simulated-environment type of game, essentially blindfolded but
> all necessary detail being dictated to me by someone beside me,
> I think one of the first questions I would ask is "where the
> heck am I". Simple enough I think. One of the most basic
> things I can imagine asking when I'm lost and (usually)
> amnesic.

Usually, where you are is the only single piece of information
you're sure about at the start of an amnesia game, isn't it? So
immediately asking, "Where am I?" is redundant. Aren't you much
more likely to ask: "Who am I?"

> The problem is, nobody thinks to include the ability for the
> game to understand that simple question: Where am I.

That may be so, but I don't see that as a problem.

> So as a test I loaded up five games: Curses, Spider and Web,
> Shrapnel, Theatre, and The Space Under the Window (I haven't
> played all of these but I'll submit that they're likely all
> excellent games. My comments are not meant as criticism of the
> games themselves but to the envelope they're delivered in).
>
> Here's the responses I received to the question "Where am I":
>
> Curses--That's not a verb I recognize.
> Spider and Web--That's not a verb I recognize.
> Shrapnel--That's not a verb I recognize.
> Theatre--That's not a verb I recognize.
> The Space Under the Window--Currently there is no "where am I" near the
> narrative (all illegal entries are treated with this response)
>
> What is my point? That I should have used the word "look" to
> find out where I am.

Or, as has been urged, read the text on the screen.

> I should have known that, shouldn't I? But why?
>
> The reason I should have used the word "look" is because that's
> the way games have always done it. Had the programmers felt a
> need to code up a WhereIs [Noun] verb, a simple verb/noun
> grammar, it would have fixed the problem. But it's not worth
> it, because they know we'll use the word "look".

Forcing players to type, "Where am I?" instead of "Look"
ultimately won't make much difference, will it? At first,
seasoned IF players will be stymied, but after they get used to
it, they'll just be annoyed. I doubt newbies will care either
way.

You're not suggesting an important change. Would "Curses" be more
fun if the SAVE command were called BOOKMARK instead?

> Multiply this assumption by all of the assumptions we walk into
> a game carrying (Floyd, bring me the ladder) and you've got a
> gaming interface that hasn't really progressed beyond
> Hitchhiker's Guide to the Galaxy in a real sense. We're
> unwittingly allowing ourselves to fall into a pattern of coding
> that hasn't changed in years.

Changing the envelope will not help anybody make better games.
What's important is what's inside the envelope, isn't it?

> We're allowing the envelope, the gaming platform, to make
> design decisions for us.

Sure, the system makes a lot of decisions for you -- if you let
it. As you may have noticed from your one command in "The Space
Under the Window", you can throw out the entire command structure
if you want to. The current systems don't force you to, for
example, Include "Grammar".

Play Shrapnel to see a surprising way for the conventional IF
commands can be turned against you.

> There's a huge role for the current players, that need not be
> said. What we need is some innovation, and more importantly
> some encouragement given those who wish to take a stab at
> creating their own system. We as IF fans depend on new
> standards being created, not adherence to older standards
> simply because it's easier that way.

In some sense, we do depend on old standards. If I had to learn a
new interface for every IF game I downloaded, I'd be at a
disadvantage.

You seem to be a dreamer, and that is a great thing to be.
I agree that innovation *is* necessary, and interesting when it
happens.

Here's one example where, possibly, the envelope did damage its
contents (this is my own speculation): Jon Ingold invented
"Novel" mode for his game, "My Angel". He unfortunately had to
allow this innovation to be turned off, due to limitations of the
z-machine interpreters that his game had to run on. It's possible
that this compromised his artistic vision in a small way. But he
may not have been able to make his game available at all without
the z-machine and its compiler.

But there are many, many examples of innovations that took place
within the current standards. For examples you have already
downloaded, try "The Space Under the Window" and "Shrapnel".

And work is constantly and already in progress to improve the
envelope. Take a look at Glulx, HTML-TADS, Hugo, PAWS, etc...

So by all means, enter the fray! But you won't really be a
pioneer.

--
Neil Cerutti
cer...@trans-video.net

Neil Cerutti

unread,
Jul 6, 2002, 11:10:24 AM7/6/02
to
On Sat, 06 Jul 2002 00:23:16 GMT in
<ULqV8.1411$St6.15...@newssvr13.news.prodigy.com>, Kevin

Forchione wrote:
> "John" <nojgoa...@hotmail.com> wrote in message news:_5oV8.1812
>> Now, I know that I have opened a can of worms here. Without
>> more context this is going to be hard to justify. Take my
>> word for it at this point that this is a good idea. What I am
>> trying to show is that there is something that these systems
>> do not enable you to do. If there is a system that allows
>> this, I would be interested in seeing it.
>
> In terms of the class / object model, yes, that is probably
> true. A dynamically created object reflects the class that it
> was instantiated from. The systems do not, for instance, let
> you create an object from a class or object that isn't already
> pre-defined, so to speak.

You can in Don Schaer's "Inform School", but only for educational
purposes. ;-)

--
Neil Cerutti
cer...@trans-video.net

John

unread,
Jul 6, 2002, 1:55:48 PM7/6/02
to
Big snip!

>> 2. Your energies would probably be more appreciated in
>> raising the existing technology to your standards,
>> rather than bashing the "establishment" in favor of
>> your own, not-yet-existing system.
>>
>> Doing this leads to the existing community feeling that
>> it's under another pointless attack (any community is
>> like this), and some will try to defend themselves,
>> leading to the annoying, "mad-scientist-esque"
>> persecution complexes that some people around here seem
>> to have.

I agree that bashing the establishment would be bad. I would like to make
sure though that I am not bashing anything. If someone thinks I am, please
let me know.

I love the current state of text adventures. I want to add my 2 cents to it
in a productive way if I can. I would hope that people would not become
defensive of what I produce and not even try it (assuming I can even create
it :-) ).

I am not trying to change text adventures, even if I could.

John.


wo...@one.net

unread,
Jul 6, 2002, 4:30:28 PM7/6/02
to

Hi John,

>It would seem that this has been done a number of times with each of the
>systems. The problem I have found though is that this code is not visible.
>People create these scripts and the builder takes those and creates a
>mechanism to parse the users input.
>

>I would appreciate any pointers to either opensource projects or other
>information in this area. Also if there are good natural language
>processing books geared to text adventures I would also be interested.
>Also, if there is a better place to ask this question please let me know.

The PAWS parser is very well documented, it's written in Python
so the source code is visible, you can find the file at:

http://w3.one.net/~wolf/PAWS.shtml


Respectfully,

Wolf

"The world is my home, it's just that some rooms are draftier than
others". -- Wolf

John Colagioia

unread,
Jul 7, 2002, 8:45:12 AM7/7/02
to
John wrote:
> Big snip!
[...ditto...]

> I agree that bashing the establishment would be bad. I would like to make
> sure though that I am not bashing anything. If someone thinks I am, please
> let me know.

I was actually responding to the (small) assortment of "people doing
their own thing is the only way to escape our mire of stagnation"
comments.

I wouldn't classify your comments as "bashing," by any means, but I
can see how some might be offended by your insistence that "things
cannot be done" in systems you haven't taken the time to examine.

[...]


> I am not trying to change text adventures, even if I could.

Oh, don't get me wrong. Change is a very good thing when it's useful
or interesting. When it's done "just because" or to "avoid sameness"
(which doesn't exist), then it's a pretty bad thing.

It's also pretty bad when the change is presented in such a way as to
alienate any users (again, I point to IBM's RealPhone and RealCD
applications) that might have benefitted from the change...

Since you seem to want to play with NLP in an IF environment, I would
heavily suggest learning Inform. The Z-Machine, and hence the Inform
language, has some inbuilt lexical capability, which should give you
a decent boost in the direction of parsing. Hand in hand with that,
also read through at least Section 36 of the Inform Designer's
Manual, which deals with leveraging the existing parser to deal with
a different input language than the common English subset.

There's also source code on the archive for Eliza in Inform which,
while not really approaching NLP, might give some vague hints about
direction.

John

unread,
Jul 7, 2002, 2:49:19 PM7/7/02
to
Wow!!! Thanks!

When you say well documented, you mean WELL documented. Your code is a
breeze to understand with all of the comments you have added. Its a shame
we don't have compilers that can take english comments and produce
bytecode!!!

John.

<wo...@one.net> wrote in message
news:fnkeiukg2ifob6ugb...@4ax.com...

DarrenH

unread,
Jul 8, 2002, 10:16:51 AM7/8/02
to
> In particular, most of the games mentioned come from the
> Infocom standard; the instructions of those games described
> the use of "look."

That's my point. Infocom as a company was essentially defunct about 13
years ago. Shouldn't we be trying to plow new turf?

> I'm fairly sure it's not unwitting; at least, not for all
> programmers. In the case of many of the games you mention,
> it was (presumably) a considered decision to mimic the
> "look and feel" of Infocom's line.

Again, that's my point.

> Or, ask things like "how can this particular thing be done
> in existing systems?" I have yet to find, after five years
> of tinkering (which may soon result in an actual game),
> anything that (a) can't be done in Inform which (b) can be
> done at all easily in another language, IF or not.

> 2. Your energies would probably be more appreciated in


> raising the existing technology to your standards,
> rather than bashing the "establishment" in favor of
> your own, not-yet-existing system.

I'm not bashing any perceived establishment. I'm saying that if one wishes
to write the engine for their own IF it shouldn't be as if one is burning a
bible.

Inform is one of the great tools we have for IF; it's not impossible to
improve on it, but I doubt most people would bother trying. It allows a
true programming environment, where IF writers can create their own commands
and alter existing ones.

Now the minute you allow change to the standard libraries you're changing
Inform. Why is that somehow not considered heresy and my suggestion is?

> 3. Unless the resulting system is provably better in
> many respects, don't expect anyone to flock to your
> banner. In many ways, an "almost perfect" system
> can seem like a greater failure than a sparse proof
> of concept.

I'm not asking writers to flock to my system. I was talking about creating
a proprietary system that, to the player, produces an end result as good as
or better than an Inform interface, except that it's not open-source.

Creating another open-source standard wouldn't do anybody any good. No
popular programs in any other genre are open-source (to my knowledge), such
should be the case for IF, in my opinion.

Linux can't really be brought up as an example to contradict my point here.
Linux isn't on it's way to taking over desktops by any stretch of the
imagination (sorry if you're on a Linux box).

> I can think of at least five "new systems" off the top
> of my head which started with the best of intentions,
> but shot themselves in the foot by failing to do one
> or more of the following:
>
> - Materialize. As I said, it's hard.
> - Maintain most of the advantages of existing systems,
> including error recovery ("That's not a verb I
> recognize") and portability.

I see that message in Inform games all too often.

> - Create a standard library, so programmers needn't
> write their own "take" verb, for example.
> - Be extensible, so programmers *can* write their
> own "rant" verb, if they need it.
> - Succeed in its original goal. A system that's
> "just like TADS," but with one new feature that
> doesn't actually work, isn't compelling.
>
> A "good" system also needs (as I think has been said
> many times, around here) a good game to show it off,
> spurring the imagination of potential users, and
> makes sure there aren't any glaring omissions in the
> system.

I agree. 'Curses' was that for Inform....

> Would any of the existing system designers like to
> tell me that I'm talking through my...uhm...hat? I'd
> *love* to hear that this stuff is much easier than
> I'm making it out to be. I hate being the cynical
> one...
>
> [...]
>
> OK, I've (yet again) ranted *more* than enough.
> Hopefully, there's something useful, or at least
> interesting, to someone, somewhere in this mess...

Your opinions are valuable to me, for one. I hope others agree. Thanks for
joining in.

Cheers,
D

Richard Bos

unread,
Jul 8, 2002, 10:55:37 AM7/8/02
to
"DarrenH" <jer...@overtime.ca> wrote:

> > In particular, most of the games mentioned come from the
> > Infocom standard; the instructions of those games described
> > the use of "look."
>
> That's my point. Infocom as a company was essentially defunct about 13
> years ago. Shouldn't we be trying to plow new turf?

Shakespeare died centuries ago, and he'd have understood the verb
"look". Why change what works? What's wrong with "look"?

> > 2. Your energies would probably be more appreciated in
> > raising the existing technology to your standards,
> > rather than bashing the "establishment" in favor of
> > your own, not-yet-existing system.
>
> I'm not bashing any perceived establishment. I'm saying that if one wishes
> to write the engine for their own IF it shouldn't be as if one is burning a
> bible.

Your feelings are your own.

> Now the minute you allow change to the standard libraries you're changing
> Inform. Why is that somehow not considered heresy and my suggestion is?

Your suggestion isn't considered heresy, it is considered unlikely to
work. It's up to you to prove that it does work.

> > 3. Unless the resulting system is provably better in
> > many respects, don't expect anyone to flock to your
> > banner. In many ways, an "almost perfect" system
> > can seem like a greater failure than a sparse proof
> > of concept.
>
> I'm not asking writers to flock to my system. I was talking about creating
> a proprietary system that, to the player, produces an end result as good as
> or better than an Inform interface, except that it's not open-source.

Then it had better have _damned_ good documentation, or nobody is going
to be able to use it to its full potential.

> Creating another open-source standard wouldn't do anybody any good. No
> popular programs in any other genre are open-source (to my knowledge), such
> should be the case for IF, in my opinion.

gcc?

Anyway, what is so good about a closed-source standard, then? What makes
it better than the existing systems? All I've seen are claims _that_ it
would be better. But claims are a dime a dozens. Show me _how_.

> > - Maintain most of the advantages of existing systems,
> > including error recovery ("That's not a verb I
> > recognize") and portability.
>
> I see that message in Inform games all too often.

So how would you solve this problem? Humungous verb vocabularies are
little help, because

- I can always think of a verb you haven't thought of;
- if you aren't going to code a differentiating response for all your
recognised verbs, you might as well not have them.

So, unless "bringle the dragon" is going to tell me something else than
that dragons can't be bringled (and, you know, perhaps they can, but you
just didn't know that verb), what advantage do you propose?

Richard

OKB (not okblacke)

unread,
Jul 8, 2002, 12:05:42 PM7/8/02
to
DarrenH wrote:

> Infocom as a company was essentially defunct about 13
> years ago. Shouldn't we be trying to plow new turf?

I mean no offense by saying this, but reading those words made me laugh out loud. New turf is
being plowed at an astonishing pace!

> Inform is one of the great tools we have for IF; it's not
> impossible to improve on it, but I doubt most people would
> bother trying.

This I completely disagree with, but I'll say no more about it since that's not the issue here.

> Now the minute you allow change to the standard libraries
> you're changing Inform. Why is that somehow not considered
> heresy and my suggestion is?

I think most people around here don't consider your suggestion "heresy"; they just don't expect a
new IF system to be any better than the existing ones.

> I'm not asking writers to flock to my system. I was
> talking about creating a proprietary system that, to the
> player, produces an end result as good as or better than an
> Inform interface, except that it's not open-source.

This is puzzling to me. Are you suggesting that a proprietary system should exist just for its own
sake? That is, are you proposing a new IF system which differs from existing systems only (or primarily)
in that it has a more restrictive distribution license? Perhaps I'm being dense, but I don't see why
anyone would want to switch to such a system from a full-featured, powerful, existing system. What
would be the advantage of doing so?

> Creating another open-source standard wouldn't do anybody
> any good. No popular programs in any other genre are
> open-source (to my knowledge), such should be the case for
> IF, in my opinion.

I sort of agree with the first sentence, for the same reason I've mentioned earlier: everyone is
happy with the existing systems! I get the impression that very few people are feeling an urgent need for
a new development system -- and I've NEVER heard anyone say anything to the effect of "Gee, it'd be
nice if I had a system just like Inform, only proprietary instead of open-source." Personally, I switched
from Inform to TADS3 because the latter seems a lot more powerful and less arcane, but if TADS3 didn't
exist, I'm sure I could have continued to use Inform indefinitely -- and these are decisions made based on
the languages and libraries themselves, irrespective of the licensing.

Your second sentence above is another puzzler. Again, you seem to be suggesting that we should
move from open- to closed-source "just because". Regardless of which distribution license you prefer, this
doesn't seem like a compelling reason.

In short: if creating a new open-source standard won't help, what makes you think a new closed-
source tool WILL help?

L. Ross Raszewski

unread,
Jul 8, 2002, 12:29:13 PM7/8/02
to
On Mon, 08 Jul 2002 14:16:51 GMT, DarrenH <jer...@overtime.ca> wrote:
>> In particular, most of the games mentioned come from the
>> Infocom standard; the instructions of those games described
>> the use of "look."
>
>That's my point. Infocom as a company was essentially defunct about 13
>years ago. Shouldn't we be trying to plow new turf?

There are lots of things that were invented quite some time ago, that
are stil used in, more or less, their original form, because the
original form "worked" -- or, more particularly, the original form was
*very well suited to the task.*

Take, for instance, the swiss army knife. Yes, things are added to it
over the years -- my own has a pen instead of a toothpick -- but it's
fundamentally the same thing it was when it was invented; it's based
on the same mechanical principles, it operates in the same way, etc.

Or take, for example, the wheel. The wheel was invented quite a few
years ago. No one tells Ponitac that they should "plow new turf" and
invent a car using some new non-wheel technology.

Change for change's sake is not a good thing. Variety for variety's
sake is not a good thing. Change and variety are good things only when
there's something an alternate can offer that the original doesn't.

>
>I'm not bashing any perceived establishment. I'm saying that if one wishes
>to write the engine for their own IF it shouldn't be as if one is burning a
>bible.

Actually, no one here is liable to come to your house and throttle you
for writing a new IF engine. We're not impugning your character. WHat
we *are* doing is warning you that you're abotu 99.9% certain to
produce an inferior engine (accordign to the overwhelming weight of
historical evidence), and you're almost certainly wasting your time,
because it is parently unlikely that there *is* any useful new ground
to cover.

>Now the minute you allow change to the standard libraries you're changing
>Inform. Why is that somehow not considered heresy and my suggestion is?
>

Because you're not. Inform's standard libraries aren't Inform.

>
>I'm not asking writers to flock to my system. I was talking about creating
>a proprietary system that, to the player, produces an end result as good as
>or better than an Inform interface, except that it's not open-source.

But the thing is, over the years, lots of people have done just that:
created a proprietary system and claimed it was as good or better than
inform. They have *always* been wrong. Every proprietary IF system
out there sucks. Almost all 'non-big-three' systems suck. I'm not
saying this because I'm a snob, or because I think it's a logical
necessity that your engine will suck, I'm saying this on the strength
of the evidence.
Yes, someone *could* write a new engine that would be wonderful. But
odds are that said person will not be you, for any given 'you'.
We've been writing IF engines for over a decade now, and we've only
managed to come up with three really good ones, so I think it's
understandable that we're cautious when someone comes along and offers
to lift us out of the darkness with their new UberEngine.

>
>Creating another open-source standard wouldn't do anybody any good. No
>popular programs in any other genre are open-source (to my knowledge), such
>should be the case for IF, in my opinion.
>

See, I don't see the sense here. You remind me of a thread on another
newsgroup long ago when someone said "Your game will sell better if
you raise the system requirements". What is to be gained from making
your engine proprietary? The only thing i can think of is a (very)
few bucks to you.

>
>I see that message in Inform games all too often.

You see it for 'abusive' uses: you like to ask things of the game that
aren't playing by the Rules of IF (IIRC, this whole thing began with
'I wanna ask the game 'Where am I?'').

Most newbie engines can't even play by the normal rules, and aren't
capable of supporting your Exceptional Rules.

Odds are, your system would support 'Where am I?' but wouldn't have
the facility to make it understand, say, "what is going on?"

DarrenH

unread,
Jul 8, 2002, 12:42:45 PM7/8/02
to
> I mean no offense by saying this, but reading those words made me
laugh out loud. New turf is
> being plowed at an astonishing pace!

I'll agree in part with this....for example, Adam Cadre's "Shrapnel" is one
of the stories I think of that seems least limited by the "envelope" (the
Infocom standard). A great game.

You may say that I'm putting the cart before the horse here. But I'll say
what I'm thinking and let the ridicule rain down. :)

I'm suggesting that creating proprietary systems may (I stress MAY) be the
way to increase the 'percieved value' of IF and that, properly marketed,
there's no reason why interactive fiction couldn't actually begin paying for
itself again (in terms of developer time). I don't see how it can be as
effective without the engine being a closed, proprietary system.

For one thing, when IF is created with an existing engine the game is part
of the engine itself, it relies on the engine to exist and indeed lives off
of the intellectual investment made by Infocom, Inform and TADS creators.
Commercially this is rather messy (It could be argued that the same could
also be said of web pages that take advantage of specific features of, for
instance, Internet Explorer, but the internet hasn't proven to be as
lucrative as anyone thought and Microsoft still needs to give the browser
away. There was a time when you had to buy Netscape. But I digress).

I liked the idea of creating a proprietary engine mainly for this reason,
and of course the other reason: I wanted to see if I could do it. There's
always a creative drive for this sort of thing, but if it can become a
commercial venture it can't hurt IF; it can only help in ways I've spoken
about previously.

So there's no reason for players to install games made for a proprietary
engine. Other than to play a good game, if there is one. That in the end
is the only driving factor.

Am I wrong with any of this? Perhaps. But I'm talking about it in order to
find that out.

Cheers
D

D. Jacob Wildstrom

unread,
Jul 8, 2002, 1:05:37 PM7/8/02
to
In article <n9hW8.1091$f5.68744@news>, DarrenH <jer...@overtime.ca> wrote:
>> In particular, most of the games mentioned come from the
>> Infocom standard; the instructions of those games described
>> the use of "look."
>
>That's my point. Infocom as a company was essentially defunct about 13
>years ago. Shouldn't we be trying to plow new turf?

<shrug> We can and do -- but media have conventions. Even in static
text, there are established conventions: works are divided into
chapters at major division points, and a change in topic or scene is
indicated by a paragraph break -- or in extreme cases, by a paragraph
break and a row of bullets. Dialogue after the first naming of the
characters need not mention the characters speaking each line (a
convention which would no doubt confuse the unfamiliar, and even
confuses the familiar when done poorly).

Move to media more complicated than text alone, and the conventions
become less intuitive. Comics feature moovles, stars, speech bubbles,
and onomatopoeia. Film is perhaps the least convention-bound medium
simply because it's closest to real-life experience -- by and large
the conventions seem designed to approximate real-life experience and
facilitate the communications process: i.e. character names are elided
in dialogue in text because it would become tedious; moovles and
speech bubbles are used in comics because static pictures cannot move
or speak to the reader.

(Aside: text-placement conventions in comics are, when you get down to
it, pretty damn confusing. Text at the top or bottom of a panel is
often either narrative or internal monologue. Text in round speech
bubbles is spoken; angle brackets indicate foreign language speech,
unusual fonts or bubble styles indicate mood, language, or even the
speaker (the first and third of these, at least, are exemplified by
Neil Gaiman's _Sandman_). Text in double-bordered, or square bubbles
can indicate everything from computer output to telepathic
communication. As a newcomer to the medium, except by context,
determination of the significance of each of these styles is
difficult)

So that brings us to IF, then. The conventions of IF are hampered by
technological limitations: natural language processing isn't advanced
to the point where we can accept arbitrary input, so there are fairly
rigid conventions on input. This can indeed be bewildering to the
user. Add to this the fact that it's an _interactive_ medium and the
difficulties of convention multiply: if something sufficiently
bewildering comes up in a non-interactive medium, the viewer shrugs
and just looks at the rest of the experience: his experience is
diminished but not ruined. If IF confuses a person, they tend to get
stuck and can't move further in the story; this ruins the experience.

IF is clearly a difficult medium, and it's extraordinarily easy to
alienate newcomers to the medium by fairly minor omissions. I don't
think this is a problem with us as such -- except insofar as we could
make the medium conventions more well known -- but with the medium and
its technological limitations. Where we stand now is not unlike the
situation of Byzantine and Gothic painters: it was difficult for them
to convey the idea of something further back in the picture from
somethnig else, and the medium only improved not through improvements
in the skill of painters, but through the technological advances which
laid the mathematical foundations for perspective.

Note also that conventions -- which are central to the gist of this
post -- are merely facilitators for appreciation, and that their
omission has, when done well, been an artistic touch in several media:
however the works so produced, although possessing merit, are often
more difficult than their convention-driven fellows to comprehend. As
examples, James Joyce is widely regarded as, although brilliant, hard
to read. Similarly, convention-defying IF, such as Failsafe and
SUTWIN, and possibly Shrapnel and Rematch, may be frustrating or
confusing.

So we use LOOK basically because it's what we expect. Not much of an
answer, but it happens in every medium.

L. Ross Raszewski

unread,
Jul 8, 2002, 1:15:15 PM7/8/02
to
On Mon, 08 Jul 2002 16:42:45 GMT, DarrenH <jer...@overtime.ca> wrote:
>
>You may say that I'm putting the cart before the horse here. But I'll say
>what I'm thinking and let the ridicule rain down. :)

Okay. Here's your ridicule.

>
>I'm suggesting that creating proprietary systems may (I stress MAY) be the
>way to increase the 'percieved value' of IF and that, properly marketed,
>there's no reason why interactive fiction couldn't actually begin paying for
>itself again (in terms of developer time). I don't see how it can be as
>effective without the engine being a closed, proprietary system.
>

How many times to we have to go through this? THere is *no commercial
future for IF.* There is *no commercial future for IF*. One more time,
everybody.

>For one thing, when IF is created with an existing engine the game is part
>of the engine itself, it relies on the engine to exist and indeed lives off
>of the intellectual investment made by Infocom, Inform and TADS creators.
>Commercially this is rather messy (It could be argued that the same could

Um. No, it's not. Inform has a license telling you that you can use it
for commercial products.

>
>I liked the idea of creating a proprietary engine mainly for this reason,
>and of course the other reason: I wanted to see if I could do it. There's
>always a creative drive for this sort of thing, but if it can become a
>commercial venture it can't hurt IF; it can only help in ways I've spoken
>about previously.

Wait. What? I still don't see how there's any advantage to a
proprietary engine beyoind the fact that you could make a very small
amount of money off of it.

>
>So there's no reason for players to install games made for a proprietary
>engine. Other than to play a good game, if there is one. That in the end
>is the only driving factor.
>

Wait. What? I mean, seriously, is there a missing sentence here?

There is no reason for me to install games made with a free engine
other than to play them.

You want what, that all games made using your engine be for pay, so if
I want to play it, I must buy it. THis is not insane in and of itself,
but, of course, it begs the question, if I'm only going to buy "good"
games, where will I find them? I'm not going to randomly buy a game
(In fact, I will probably *never* buy a text adventure ever again),
without the strength of reviews, marketing whatnot. And I don't expect
you to reinvent the commercial IF empire.

>Am I wrong with any of this? Perhaps. But I'm talking about it in order to
>find that out.
>

I can't tell if your wrong, I can barely make sense of what you're
saying.

DarrenH

unread,
Jul 8, 2002, 1:40:51 PM7/8/02
to
Well, thanks for obliging me in the ridicule department. ;)
Seriously, I appreciate your feedback.
Cheers
D

"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:DMjW8.6719$Tb4....@nwrddc02.gnilink.net...

DarrenH

unread,
Jul 8, 2002, 1:59:28 PM7/8/02
to
[other points read but snipped in reply]

> Change for change's sake is not a good thing. Variety for variety's
> sake is not a good thing. Change and variety are good things only when
> there's something an alternate can offer that the original doesn't.

Agreed. But change for change's sake is better in my view than adherence to
old ways simply for adherence to old ways' sake. As it is said, your
mileage may vary.

> Actually, no one here is liable to come to your house and throttle you
> for writing a new IF engine. We're not impugning your character. WHat
> we *are* doing is warning you that you're abotu 99.9% certain to
> produce an inferior engine (accordign to the overwhelming weight of
> historical evidence), and you're almost certainly wasting your time,
> because it is parently unlikely that there *is* any useful new ground
> to cover.

I'm glad for the first part of your statement. I'm not sure about the
second part, it rings mildly of the quote I remember being uttered by a
patent officer in the early part of the 20th century that suggested closing
the patent office because there's nothing new of use that could be invented.

> But the thing is, over the years, lots of people have done just that:
> created a proprietary system and claimed it was as good or better than
> inform. They have *always* been wrong. Every proprietary IF system
> out there sucks. Almost all 'non-big-three' systems suck. I'm not
> saying this because I'm a snob, or because I think it's a logical
> necessity that your engine will suck, I'm saying this on the strength
> of the evidence.

Agreed. There's some bad, bad stuff out there. Hilariously bad. Which
doesn't make my argument very good. But that doesn't mean it can't be done,
it just means that it's a difficult task that most people don't have the
drive to finish. It's like dismissing a camera because no good photographs
could be taken with it; we all know that the ingenuity is in the
photographer.

> Yes, someone *could* write a new engine that would be wonderful. But
> odds are that said person will not be you, for any given 'you'.
> We've been writing IF engines for over a decade now, and we've only
> managed to come up with three really good ones, so I think it's
> understandable that we're cautious when someone comes along and offers
> to lift us out of the darkness with their new UberEngine.

Well, I'm not suggesting I'll have the UberAnswer to all of life's problems;
that's for sure. Being able to code an Inform-level game engine is
definitely possible, however.

It's more difficult to code an engine that is as programmable in the
traditional sense as Inform, but that wouldn't be my goal in this exercise.

> See, I don't see the sense here. You remind me of a thread on another
> newsgroup long ago when someone said "Your game will sell better if
> you raise the system requirements". What is to be gained from making
> your engine proprietary? The only thing i can think of is a (very)
> few bucks to you.

I'm not really into anything for the money. You don't know me but I guess
it's good enough to know that I'm into IF...right there we don't have the
world's biggest income stream. :)

> Odds are, your system would support 'Where am I?' but wouldn't have
> the facility to make it understand, say, "what is going on?"

Interesting suggestion.

Cheers,
D

Daniel Barkalow

unread,
Jul 8, 2002, 2:10:42 PM7/8/02
to
On 8 Jul 2002, OKB (not okblacke) wrote:

> DarrenH wrote:
>
> > Infocom as a company was essentially defunct about 13
> > years ago. Shouldn't we be trying to plow new turf?
>
> I mean no offense by saying this, but reading those words made me
> laugh out loud. New turf is being plowed at an astonishing pace!

Advances (which are substantial) have been in other aspects of the game
experience than the parser since about Curses. It's a little bit beyond
the Infocom parser ('X' is a godsend, and there are a number of new
conventions which make games much more playable), but it hasn't really
advanced significantly, recently, at least in the Z-mchine/GLULX world
(aside from Platypus, which hasn't really caught on).

There's turf enough to plow in the content side without needing more in
the interface, but that doesn't mean the interface couldn't use work as
well.

> > Creating another open-source standard wouldn't do anybody
> > any good.
>

> I sort of agree with the first sentence, for the same reason I've
> mentioned earlier: everyone is happy with the existing systems!

I disagree here; there are a number of features that people would probably
like. However, the Inform license is a bit inconvenient for this: you're
not supposed to distribute a modified version of Inform without Graham's
permission, and Graham doesn't tend to participate in conversations these
days. At least when I was following it, the author of Platypus hadn't
managed to get permission to distribute it, although Graham (it turns
out) couldn't have been unaware of it, and he didn't complain.

Of course, we are currently a somewhat insular group with a canon; people
who play new games will likely first play some of the older port-Infocom
games, and will thus know the behavior of the libraries when approaching a
newly-written game. Things like "parse everything as a command, not a
question" have been sufficiently ingrained that people probably wouldn't
think to ask a new game questions unless the game actually mentioned that
this was possible. My personal thing is looking in directions. It often
seems like a sensible and useful thing to do, and the library responds to
it, but not in a way that's easy to make part of a game. If I ever
finished a game, I would feel it necessary to mention that you could get
useful results that way.

Features I think would improve Inform:

- Questions:
"where is {noun}" should tell you the last known location of
the noun, with some extra information (do you know it's gone? Do you
know it tends to move around?)
"what is {noun} set to", "is {noun} on", etc.
- Remembered dialogue:
You ought to be able to get a repeat of conversations without actually
having the conversation again. Especially when you put down a game
for a few months, and the NPCs don't repeat themselves.
- Go (toward) location:
Not everyone likes this, but it should at least be an option in the
library; pathfinding based on known stable room connections, where
each command takes a single step along the path to the given
location.
- Looking in directions:
The descriptions of the walls, ceiling, floor, and the dark should be
properties of the room, with library defaults.
- A bunch of intermediate actions, and general assumed action chains
It should be easy to catch any action which requires touching an
object, at the point of touching it; likewise getting close to it. It
should be easy to add a chain of actions that the game will attempt
when you try something. "[First opening the door] [First unlocking
the door with the gold key] [First getting the gold key from your
backpack]" when you try to go north through a door you've previously
used the gold key to unlock.
- Cleaner and more elaborate scope
My Scoper extension would work a lot better inside the library, and it
would be easier (with intermediate actions) to get the right behavior
for everything and easier to use it.
- More powerful message generation
This has shown up (somewhat) in Platypus; you ought to be able to get
the library to deal with pronouns in combined messages ("The queen
ignores you. She leaves to the north.").
- Actions for NPCs
Again in Platypus but not the standard library; there's no way to use
the library to determine if, by the standard simulation rules, an NPC
would be able to pick up an object. This makes it hard to have both
NPCs who follow instructions and situations which would prohibit
those actions.

The problem is that these features all go pretty deep into the library, so
add-ons can only handle them somewhat. Furthermore, having a non-standard
library won't cause enough new games to use these features that they'll
become part of the canonical interface.

Actively developing a reworking of the standard library as a group project
(since individual library developers seem to get burnt out
eventually) would be good, but isn't really permitted by the Inform
license. And getting to the level of the standard Inform library from
scratch is very difficult, because it is actually very extensive.

Daniel Barkalow

unread,
Jul 8, 2002, 2:14:49 PM7/8/02
to
On Fri, 5 Jul 2002, John wrote:

> That said, one of the major parts of what I am trying to do is create new
> objects dynamically. For instance, the user can create a hammer and then
> use that hammer to do things.

You might actually want to look at TinyMUD (and its derivatives), which
are intended to allow the creation of more stuff by the user (or, at
least, internally to the system).

John W. Kennedy

unread,
Jul 8, 2002, 1:57:25 PM7/8/02
to
DarrenH wrote:
>>In particular, most of the games mentioned come from the
>>Infocom standard; the instructions of those games described
>>the use of "look."
>
> That's my point. Infocom as a company was essentially defunct about 13
> years ago. Shouldn't we be trying to plow new turf?

If some people who have degrees in natural-language processing
and artificial intelligence want to make the try, maybe. That's
what the Infocom founders had. But I would not recommend trying
to outguess them starting from scratch. This is an intrinsically
hard area, devilishly difficult to program even with an established
codebase and established conventions. For a lone programmer working
in his spare time, it is probably insurmountably difficult, especially
as someone currently working in the field cannot rely on half the
population of the Internet actively (in effect) beta-testing the
game, as was the case for mainframe Zork.

> Now the minute you allow change to the standard libraries you're changing
> Inform. Why is that somehow not considered heresy and my suggestion is?

Stop using words like "heresy". They show that you're either missing
the point, or just being a troll.

The issue is simply that it is madness to suggest to a sole
programmer with no knowledge of either field to strike out
blindly in a project that requires both artificial cognition
and natural-language parsing, while also insisting that he
dismiss prior art.

At the very least, you could at least have the gumption to
do it yourself, before recommending it to others.

> I see ["That's not a verb I recognize."] that message in Inform games all too often.

Good luck typing the entire Oxford English Dictionary into your system.
Not to mention trying to get YACC to process a grammar with several
tens of thousands of productions (a conservative estimate).

--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood.html

John W. Kennedy

unread,
Jul 8, 2002, 2:14:58 PM7/8/02
to
Kevin Forchione wrote:
> TADS can't do this kind of thing, per se, because classes can't be
> dynamically composed at runtime. In fact, neither can Java or C++.

Java can, with some effort and use of the Reflection feature. But
only the LISP family can do it easily.

DarrenH

unread,
Jul 8, 2002, 2:52:06 PM7/8/02
to
Thanks for your reply Daniel. I appreciate that, regardless of your
position on the subject, you have not taken a black/white stance on it. I
have not attempted to polarize the discussion, and I hope that it's not
interpreted that way. I'm not trying to replace anything, simply add
another spice to the mix.

Your suggestions are very interesting. Are you on a Windows platform?
Without trying to hog-tie you into something you may not have time for,
would you be interested in evaluating a game engine with a test game?

Cheers
D


"Daniel Barkalow" <iabe...@iabervon.org> wrote in message
news:Pine.LNX.4.21.02070...@iabervon.org...

DarrenH

unread,
Jul 8, 2002, 3:06:54 PM7/8/02