NLP Question
John
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
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
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
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
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
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
> 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
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
> 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
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
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)
> 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
>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
>
>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
> 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)
> 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
> 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
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
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
John.
"NSF" <sillyq...@mail.com> wrote in message
news:6d245961.02070...@posting.google.com...
John
> 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
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
>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
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
> 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
> 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
> 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)
> 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
> "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
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
> 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
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
> > 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
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
[...]
>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
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
<ULqV8.1411$St6.15...@newssvr13.news.prodigy.com>, Kevin
>> 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
>> 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
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
> 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
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
> 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
> > 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)
> 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
>> 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
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
>> 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
>
>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
Seriously, I appreciate your feedback.
Cheers
D
"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:DMjW8.6719$Tb4....@nwrddc02.gnilink.net...
DarrenH
> 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
> 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
> 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
>>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
> 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
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
> 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.
Well, I'm not a troll. I trust that my tone has been non-confrontational
from the start. I suppose I carry the wounds of a few exchanges with people
who take their Inform/TADS quite seriously, and the presence in the FAQ of
the strong suggestion that I adhere to a "specialized IF authoring system".
Thus the slight acerbic tone in that regard. I'll hold back on the
religious connotations in future.
> 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.
Definitely...I'm not saying you should abandon your working method, I'm
suggesting that I have a working method proposed as an alternative. That is
all. I have the highest respect for what Inform and TADS have done for IF.
Cheers
D
Peter Seebach
>years ago. Shouldn't we be trying to plow new turf?
Only if we're sure we're improving.
>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's substantially worse for many of us - and is at a substantial
competitive disadvantage.
>Creating another open-source standard wouldn't do anybody any good.
It'd have a better chance than a proprietary one.
>No
>popular programs in any other genre are open-source (to my knowledge), such
>should be the case for IF, in my opinion.
Well, every roguelike I can think of is open source, there's lots of good
open source solitaire games, there's open-source word processors, document
formatting, compilers... I work for a medium-big company, and we use a *LOT*
of open source software tools.
>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).
We'll see where the free software/Windows thing is in another ten years. :)
-s
--
Copyright 2002, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
L. Ross Raszewski
<iabe...@iabervon.org> wrote:
>
>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.
'A modified inform'. You don't need to modify inform for most things;
you need to write a library module. THere's only been a very few
things people have wanted that actualyl required changing inform
itself: (these are the examples I can remember)
- String-embedding of certain kinds of routines
- An XOR operator
- A higher #include limit.
And here's why you don't need to modify inform or improve the state of
IF languages:
>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.
This can be done in a couple of dozen lines of inform. No changing
inform needed.
> - 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.
This can be done very easily; a modification to, say, movies.h should
give you somethign similar to the Gabriel Knight tape recorder.
Of course, this is impossible to implement in a totally generic sense,
unless you're willing to constrain that "all NPC speech must take
place in a certain special way as to identify it as NPC speech".
> - 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.
There's a dijkstra library for TADS, and I believe it's part of a
larger add-on for inform.
> - Looking in directions:
> The descriptions of the walls, ceiling, floor, and the dark should be
> properties of the room, with library defaults.
They *are*.
> - 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.
This could be done without changing inform, but not in a general
way. However, this could nopt be done in a general wya even by
changing inform.
> - 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.
It would "work a lot better inside the library"? I don't understand.
> - 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.").
Again real easy.
> - 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.
>
Um... you *can* do this in the standard library.
>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.
(a) this is not true; it's possible to write library addons that go
far deeper than any of the things you've suggested.
(b) You seem to be pushing for "I think these following complex things
are neat, so I want them to be standard". The purpose of the library
is not to make every neat thing a standard feature. THe purpose of the
library proper is to make the core functionality available. Everythign
else belongs in an add-on. (In fact, I'd claim that even, say, domenu,
doesn't really belong in the standard library. But, of course, not so
many people actually use it nowadays preferring menus.h or altmenu.h)
Adam Thornton
Eytan Zweig
"Adam Thornton" <ad...@fsf.net> wrote in message
news:agcu1h$b0s$1...@news.fsf.net...
Counterexample among the "core" roguelikes: ADOM.
Eytan
> Adam
Andrew Plotkin
> 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)
Footnote: "X" was actually an Infocom innovation, very late in their
run. I think it showed up in _Nord and Bert_.
> 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).
Although that doesn't stop any given author from using it, since it
produces games in a well-accepted format. This is not a small point.
> Features I think would improve Inform:
(My comments on just a couple of these.)
> - Looking in directions:
> The descriptions of the walls, ceiling, floor, and the dark should be
> properties of the room, with library defaults.
This is one of those features that it's hard to take a *little bit* of
advantage of, when you're designing your game. If most of the
direction-looking in a game produces default messages, the player
is going to give up on the command entirely, quite soon.
> - 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.
Yes, I frequently pine after this. I never bother to write it, because
it's clearly a Platypus-sized job. (_Shade_'s implementation of the
feature is very very minimal -- it barely does what _Shade_ requires
of it, which isn't much.)
> - 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.").
Interesting idea. I've done small hacks for this sort of thing, on a
message-by-message basis (as have we all), but a general facility
might indeed be a transformative tool to have around.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
OKB (not okblacke)
> 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).
Ah, well then. That makes a whole lot more sense. The issue of whether it's possible to make IF
profitable is one I won't go into here, but if that's your aim, a proprietary system is certainly a reasonable
means.
OKB (not okblacke)
> 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.
That may well be. Personally, I don't think the current interface is severely broken, but sure, there
might be cool alternatives. I'd be glad to see them. (Whether this means someone has to write a
completely new, proprietary IF system is something else again.)
>> > 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.
I didn't mean that Inform (or any of the other languages) is perfect, but that it's good enough and
flexible enough that most current users are able to get the results they want. It occurs to me, though,
that a new IF system (if -- and this is a big if -- it were at least as powerful as the existing systems) could
have a future if it drew the attention of new authors.
The main problem is just inertia. People who are using a certain language aren't likely to change
to a comparable language just for the heck of it. My statement about everyone being happy was in
response to the original poster's suggestion that his planned IF system would be roughly the same as
Inform, and my point was that a system this is not likely to draw attention.
On the other hand, a system that DOES offer genuinely new capabilities is quite likely to catch
on. Despite having spent several years working in Inform, I was excited enough by the features of
TADS3 to make the switch. I was NOT motivated enough to switch to TADS2, because, although it had
some advantages, I perceived it to be in the same league as Inform. I suspect that this kind of cost-
benefit analysis is not uncommon; many people will ask themselves the question: "do the benefits of
system X outweigh the cost of the time I'll have to spend learning it if I switch to it from the system I
already know?"
> Features I think would improve Inform:
<snipped list>
As other have mentioned, most of these could be handled in a library extension -- it might be a
huge, unwieldly library extension that replaces several gigantic library routines, but it could be done.
If you're interested in those features in general (as opposed to interested in seeing those features
added to Inform), I recommend that you take a gander at TADS3; not only does it provide some of them
in the standard library, but its standard library is much more cleanly designed than Inform's, which
makes it much easier to add the features you want. (And, by looking at TADS3, and weighing the pros
and cons of developing in it, you can conduct a little experiment about the language-switching issues I
discussed above. :-)
Dan Schmidt
| On Mon, 8 Jul 2002 14:10:42 -0400, Daniel Barkalow <iabe...@iabervon.org> wrote:
| > - 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.
|
| This could be done without changing inform, but not in a general
| way. However, this could nopt be done in a general wya even by
| changing inform.
By my definition of general, TADS 3 does this in a general way. (It
handles the above example out of the box, for example.)
Dan
Joao Mendes
Hi, :)
"John W. Kennedy" <jwk...@attglobal.net> wrote in
news:3D29D6A2...@attglobal.net:
> Kevin Forchione wrote:
(about the player creating an entirely new class while playing a bit of IF)
>> 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.
I'd also like to point out that MUSH servers, like PennMUSH, also allow for
this type of thing.
The main disadvantage of allowing for something like this seems to be that
the _player_ needs to be a programmer in order to take advantage of this.
Frankly, in IF, I don't see it, but hey, I do love MUSH building, so
there... ;)
Cheers,
J.
P.S. Incidently, my wife and I decided to try our turn at building IF
before we ever new about authoring systems or this newsgroup. Believe it or
not, I had my mind made up on setting up our work on a MUSH server, but
decided to take a quick peek in google to see if anything more specific was
around. Thusly, here I am... :)
Richard Bos
Then again, ADOM sucks. So we can prove that open source games are
better than closed source ones <g>.
Richard
Richard Bos
> On 8 Jul 2002, OKB (not okblacke) wrote:
>
> > 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.
People do keep saying this, but I've yet to hear a real suggestion as to
_how_ the interface could be improved, especially in ways that cannot be
done within the current systems. Frankly, I cannot think of any. Well,
actually, I can, but they're all too munchkinish to be taken seriously -
things like use mouse buttons for the most used commands. Blech.
Richard
Richard Bos
[ Could you please leave in some contributions? Thanks. ]
> > In short: if creating a new open-source standard won't help, what
> > makes you think a new closed-source tool WILL help?
>
> 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.
Well, it would be hard to _de_crease the perceived value of IF, since
that is just about $0.001 in toto. But I wonder, how much money do you
want to spend on marketing?
> 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.
This is no more true than that zip files are part of WinZip or PKZip, or
that WinZip is part of the zip format specifications.
In fact, this is one area where open source and open standards have a
great advantage over closed source and standards: with open source you
know what you've got. If you're not satisfied with the current 'terps,
you can write a new one, because you know what it is supposed to do. If
you want to write a new compiler for use with the same 'terps, you can
do so, because you know what to compile for. You can do this no matter
if Graham Nelson is involved or not.
Contrast with your proprietary standard: if I don't like your 'terp, I
can do nothing about it. If you walk in front of a bus, or, hey, get
married and decide to spend your time in more pleasurable ways, nothing
happens to your system. _You_ are the core of the system, not the
standards.
> 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.
Ah, _that's_ a damn good reason. But do please excuse us if we're rather
sceptical about how much will actually emerge from this project.
Richard
Georgina Bensley
> > - Looking in directions:
> > The descriptions of the walls, ceiling, floor, and the dark should be
> > properties of the room, with library defaults.
>
> This is one of those features that it's hard to take a *little bit* of
> advantage of, when you're designing your game. If most of the
> direction-looking in a game produces default messages, the player
> is going to give up on the command entirely, quite soon.
Looking in directions is something I often try but rarely works, iirc... I
always want looking in a direction to let me see into the next room,
provided there is not a solid obstacle in the way. My memory is fuzzy, but
I don't think this works very often.
Or maybe even just the title of the room in that direction.
>look east
To the east you see the Kitchen.
if the door were open. If the door wasn't open,
To the east you see a door.
If there just wasn't any exit to the east,
To the east you see a wall.
(Customisable message so you could make it "a cliff face" or whatever else
prevents there from being an exit in that direction, but default to a
generic wall.)
Are there games that handle direction-looking in this fashion?
Jim Simons
wrote:
>Looking in directions is something I often try but rarely works, iirc... I
>always want looking in a direction to let me see into the next room,
>provided there is not a solid obstacle in the way. My memory is fuzzy, but
>I don't think this works very often.
<Snip>
>Are there games that handle direction-looking in this fashion?
Varicella, for one. I'm just starting that game now (working my way
back up to literacy after an absence of a few years...), and I'm
finding that being able to look in directions and through windows is
really adding to my sense of immersion. In some cases the effect
achieved could easily be handled by "x", for simple scenery that is
relatively static. "Through the window you see the intricate masonry
of the cathedral across the street." Assuming the author is not going
to add anything to that description in too dynamic a way, such as
observing the actions of NPCs ("Quasimodo is now swinging from the
bell tower", or "The colonel and Fifi are talking about ...") or the
progress of a leak or a fire in the next room ("The crackling spark
creeping along the fuse is now only eight inches from the powder keg",
etc), that description could be part of the description of the
windows, but I think something would be lost.
Breaking up "x window" and "look through window" is adding
immeasurably to my sense of immersion: that is, the sense that I am
exploring a space within a space, that I am looking at a space beyond
the window rather than just a picture on the wall. I'm taking this as
wholly apart from any story or puzzle value gained from eavesdropping
or surveillance. That angle was exploited well in Sierra's Laura Bow
mysteries way back, but only in that limited way. In those games there
was not so much the sense of this device adding to the setting. It was
either "Something important to the story/characterization/mystery is
happening in the billiard room and here it is" or "Nope, nothing
happening in the dining room right now."
And bringing this back to the subject of the thread, I note that this
effect was achieved for Varicella in Inform.
Cheers,
Jim
David Brain
(L. Ross Raszewski) wrote:
> 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.
It is highly probable that there is *no commercial future for IF*
Never say never. But this is nit-picking, and I agree.
--
David Brain
London, UK
wo...@one.net
Hi DarrenH,
>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.
IF as a commercial entity is dead, and will remain dead. I once
read a statistic that there are only about 20,000 people world
wide still interested in IF. That doesn't make a very good
seed base... :)
On the other hand, look what IF would have to compete with in
the mainstream. The graphcal adventures like Zork Nemesis or
the Myst series simply blow away IF for sheer wow factor.
IF's day has come and gone, like the sail-powered clipper ships
of old. In fact, one analogy I like to use is that IF is very
much the programming equivalent of building a ship in a bottle.
If you do your new engine for potential commercial gain, you're
going to be disappointed. If you do it for yourself and your
own satisfaction, well, that's reason enough to do anything.
Even build a ship in a bottle...
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
Garth Dighton
Better counterexample: ADOM (whether Diablo is a roguelike is frequently
debated. I've never heard anyone suggest ADOM isn't a roguelike, though)
--
Garth Dighton
gdig...@yahoo.com
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Andrew Plotkin
> IF as a commercial entity is dead, and will remain dead. I once
> read a statistic that there are only about 20,000 people world
> wide still interested in IF. That doesn't make a very good
> seed base... :)
Sounds like an excellent market to me. Any science fiction author
would be thrilled to sell 20000 copies of a $25 hardback.
Andrew MacKinnon
Look at the situation with music. The musician makes a very, very small
fraction of the cost of the CD. Big Record Company takes the rest. Same
with book authors. Same with IF authors.
Of course, if you can sell the games directly (as opposed to through Big
Software Company), you can make lots of money, assuming the games have
enough outreach.
--
Andrew MacKinnon
http://www.geocities.com/andrew_mackinnon_2000/
John Colagioia
>>In particular, most of the games mentioned come from the
>>Infocom standard; the instructions of those games described
>>the use of "look."
about 13
> years ago. Shouldn't we be trying to plow new turf?
"Not so much," as my sister likes to say.
See, here's the thing. "Look" makes some sense to some people, and a
lot of sense to people familiar with the genre. We're all together
on this point, I believe.
You can call "look" anything you want. "Look around," "l," "examine
the environment," "where am i," "what the @#$! is going on around
here," whatever you like. And, no matter what you choose, some new
people will find it "instinctive," and others won't get it. In fact,
it'll be just like it is now, except that the veterans, who you
*know* will try to play your game, will be confused and annoyed.
"So," you say (because you're now required to play Devil's Advocate
at this stage of the discussion), "that just means I just need to add
more synonyms." And, you're right, to a certain extent. The more
synonyms, the less likely a novice is to get "stuck." But, there are
two very large problems:
First, the more synonyms, the larger the programming effort, and the
larger the game. I tried this, once, plugging in every synonym I
could think of for my Inform game. When I abandoned it, it had
something like one room, two or three objects, and didn't fit on the
Z-Machine, anymore. This is only a problem if we decide not to be
snobs and favor the "technical elite" who have higher-end computers,
of course. "Everyone" has a Cable Modem and a 2GHz microprocessor,
nowadays, right...?
The other problem is far worse. The more you accept, the less you
reject. This sounds obvious, trivial, and even *good*. But it
isn't, once you start thinking about the effects. Let's say you
include the entire contents of the OED, Webster's International, and
any other dictionary you find floating around. Good, right? Any
"real" word the player uses will be recognized (at some level) by the
parser. Cool!
Except, what's the probability that the player *meant* to type "> GUT
CWM"? I don't know what the hypothetical player was planning on, but
you can be darn sure that the plan wasn't to remove the internals of
a hollow. And you can't reject it, because, what if that *was* what
the player wanted, right? You can't dismiss his synonym...
Heck, add an auto-correction feature, so that no matter what the
player types, *something* will happen...kinda like some UNIX
installations I've encountered, actually...
>>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.
OK, then, let me ask a question: Should artists who try to create
sculptures, for example, in the style of Rodin "move on"? After all,
Rodin has been dead far longer than Infocom.
Similarly with those precious few companies that still produce hand-
illuminated manuscripts? Those are very outdated, after all...
I hope those are rhetorical questions.
It's not, I don't think, an uneducated or ill-considered decision to
emulate a style which is (a) proven, and (b) fondly recalled. And if
there are limitations, I'm not sure we've reached them, yet.
I'm not saying that's a reason to stagnate, by any means. That would
be short-sighted and ignorant. However, if "we" (I say, as if this
is some kind of club with membership rules) spread ourselves too thin
chasing "what could be" without a firm enough grounding in what's
possible now, the odds are not slanted in favor of good results.
[...]
>>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.
And I don't think it *is* viewed that way. Disagreement is hardly
excommunication, after all.
I'll grant you that it can *look* like that, on rare occasions (and
the shocking occasions are much easier to remember), but keep in mind
the tone of the question. There's a big difference in subtext
(whether it is intended or not) between "why doesn't anyond do this
'obviously' superior thing?" and "I'm thinking of doing this; does
anyone see any problems up-front?"
The first question (very close to your original phrasing) carries a
subtext of "you people should be doing this," while the second takes
the implied burden (which you didn't mean to imply) off the reader's
shoulder, since it's squarely stated to be *your* project, and simply
invites discussion on the topic.
And, actually, I'm partially at fault for this. Let me amend my
original response to you, by asking what I should have asked when
responding to your question: "What problem do you see in modern IF,
that answering the question 'where am i' would solve?" Or, any of
your other proposed solutions, for that matter.
See, just like it's really easy to shout "this could/should be
better" when confronted with "the establishment," it's also easy to
jump on proposed solutions, assuming that they're just random whims
("I think this would be much better...in green"), forgetting that
there's a problem behind them that might have a *better* solution.
The problem right now is that I don't see the problem; I don't think
many other people around here do, either. In all seriousness, try to
take some time to outline the problem that *you* see, ignoring what
either of us thinks is "the state of the art," and ignoring any
potential solutions for a moment.
> 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 depends on what you mean. The language, proper, probably isn't
worth changing to any great extent (though I've heard of people doing
it), because it exposes just about everything that's in the
Z-Machine. Even so, arguably, Inform could benefit from some added
features, in all likelihood.
The library, though...In addition to dozens (hundreds, yet?) of
library additions, there's Platypus, an entirely rewritten library,
and I can think of a handful of people (including myself) who regard
the library as something that can--and should--be modified whenever
it suits the game.
> 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?
Put simply--and I'll probably repeat this somewhere, later, so please
excuse where it happens--it's a matter of cooperation. I'd much
rather, because I think you're capable of it, play in the same
sandbox I'm in, so that you can build on my experiences, and I can
reciprocate when the time comes. "Me" being any hypothetical person
using Inform or TADS, really.
You build your own system, and I might play the few games that come
out of it. If I like them, I'll even say, "I wonder how to do this
in Inform." But it'll be mostly convergent evolution and wasted,
redundant effort on one of our parts.
To put this in the simplest possible terms, I'd much rather see the
bright people (who are complaining) around here focus their efforts
on finding the weak points and overcoming them, rather than claiming
that such weak points exist, pulling up stake, and going their own,
isolated direction.
Stand on the shoulders of giants, as they say. It's better for
pretty much everybody.
>>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.
A purist might take offense at the term "open-source," which has an
annoyingly strict meaning. That the source code is freely available
does not make a project open-source.
I don't care about such things, though.
> Creating another open-source standard wouldn't do anybody any good.
I fail to see how any other standard would do well (two major
standards tends to be the maximum number a typical community can
bear, which explains the relative disinterest in Alan, Hugo, PAWS,
ADRIFT, and the twenty or so other systems lurking around).
> 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).
Technically, the Macintosh makes for a good counterexample. I'm not
familiar with the actual scheme at Apple, but the OS/X kernel is the
open-source Mach, and the remainder of the non-UI operating system is
FreeBSD, which is almost the Open Source Granddaddy.
If Carbon and Cocoa are what I think they are, almost the entire
system may very well be open source, or at least an instance of a
collection of existing open source projects.
Not that I'm a FSF fanatic--far from it, in fact. But I think my
point is that openness of construction isn't necessarily related to
popularity or usefulness.
Having said that, I *do* believe that the existing IF languages could
probably benefit from a competing system. Most of the advances in C,
for example (for better or for worse) have come from alternate
compilers adding their own extensions, which were then copies by
others. Neither TADS nor Inform has this.
Am I planning to do this? Maybe, actually. I have a project or two
brewing that may tie into it in a few months.
[...]
>>- 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.
But the point is, it's a *good* message, regardless of whether or not
it bores you. It's concise, and carries exactly the content that a
player needs to know when typing something unusual--to wit, "try a
different verb."
The message can also be changed with very little effort, which is a
very good thing, even though too few authors actually go to the
trouble.
Contrast this with other systems where the equivalent default is
something like "Eh?" or "What are you talking about?" Many systems
have a vague response that's either insulting, or doesn't convey
enough information about what might be wrong. And others have a
message that works in some games (because of the tone), but it can't
be changed.
[...]
John Colagioia
[...]
> 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.
Just to be the annoying guy who pulls out the counterexample to the
counterexample, there was quite a bit of work a few years back in
semi-triangular wheels (basically, three arcs, rather than three flat
sides). By staggering the points appropriately, they handle rough
terrain far better than traditional wheels.
Not that this is entirely relevant--just that every once in a while,
advances do happen in the unlikely spots. However, you'll note that
they started with an *existing* wheel, rather than trying to figure
out how to reduce the load on the thing they were dragging along...
[...]
L. Ross Raszewski
>
>It's not, I don't think, an uneducated or ill-considered decision to
>emulate a style which is (a) proven, and (b) fondly recalled. And if
>there are limitations, I'm not sure we've reached them, yet.
>
Exceptionally well put. But you forgot (c) effective against aliens.
>Contrast this with other systems where the equivalent default is
>something like "Eh?" or "What are you talking about?" Many systems
>have a vague response that's either insulting, or doesn't convey
>enough information about what might be wrong. And others have a
>message that works in some games (because of the tone), but it can't
>be changed.
This is a very good thing to point out. AGT was sort of classic for
havign a lot of hard-wired responses that only made sense if you were
playing a zork-clone.
Sean T Barrett
>Here, Daniel Barkalow <iabe...@iabervon.org> wrote:
>> Features I think would improve Inform:
>> The descriptions of the walls, ceiling, floor, and the dark should be
>> properties of the room, with library defaults.
>
>This is one of those features that it's hard to take a *little bit* of
>advantage of, when you're designing your game. If most of the
>direction-looking in a game produces default messages, the player
>is going to give up on the command entirely, quite soon.
Actually, the specific thing requested--descriptions of the *entities*,
not the directions--would be nice to have. Every so often, perhaps every
other game or so, I have one place where people will naturally examine
or refer to the west wall or the floor. So I add a wall or floor
scenery object, put a description on it, and when people refer to it,
the parser prints a disambiguation warning since there were two such
floors or walls. It's such a small thing it's never been worth my
effort to figure out how to get rid of that message.
Just being able to set a property on the room would be simple
and convenient, and I might not shy away from mentioning floors
and rooms as I tend to.
Maybe I'll kick out a library extension to do just that sometime.
SeanB
John Colagioia
[...]
>>> - Looking in directions:
[...]
> Actually, the specific thing requested--descriptions of the *entities*,
> not the directions--would be nice to have. Every so often, perhaps every
> other game or so, I have one place where people will naturally examine
> or refer to the west wall or the floor. So I add a wall or floor
> scenery object, put a description on it, and when people refer to it,
> the parser prints a disambiguation warning since there were two such
> floors or walls. It's such a small thing it's never been worth my
> effort to figure out how to get rid of that message.
I've been using a variation on the idea put forth in:
http://groups.google.com/groups?selm=fthr6.5392%24lA1.305923%40news.dbn.net
and it seems to be working out fairly well.
> Just being able to set a property on the room would be simple
> and convenient, and I might not shy away from mentioning floors
> and rooms as I tend to.
Yep. That's pretty much the size of it...
> Maybe I'll kick out a library extension to do just that sometime.
The only flaw I see is that there isn't an easy way to cram it into a
nice, modular library add-on; it needs to (as far as I can tell) be
hacked into the library, itself.
If you're not so worried about that, though, then you're set.
OKB (not okblacke)
[about description of walls]
> I've been using a variation on the idea put forth in:
> http://groups.google.com/groups?selm=fthr6.5392%24lA1.305923
<snip>
> The only flaw I see is that there isn't an easy way to cram
> it into a nice, modular library add-on; it needs to (as far
> as I can tell) be hacked into the library, itself.
Hmmm. The mechanism described in that post uses a before property (added to the
CompassDirection class) to catch Examine actions directed at the walls. Conceivably, you could instead
put this code inside a utility object inside your library extension, use found_in so this object "followed"
the player, and then trap Examine in a react_before. Something like:
Object SekritWallWatcher
has scenery static concealed
with
react_before [;
Examine:
if (noun in Compass) {
if (location provides compasslook) {
location.compasslook(noun);
rtrue;
}
}
];
This is kind of a shaky solution -- it could conflict with other react_befores in the game, and I'm
not totally confident about whether that "scenery static concealed" will keep the utility object totally out
of the player's way (although I used that approach in GxScript). But it is possible to put this in a library
extension.
Also, a suggestion for the interface to the game author: it seems to me it'd be handy to have
separate properties for each direction. So if only the north wall was important, I could just define a
lookNorth property equal to "The north wall bears a strange inscription" instead of having to do a big old
switch. Then there could be an additional catch-all property (say, lookWall) that could be used if a
special description was needed for all walls. So if I wanted special descriptions for the north and east
walls, and a third description (different than the library default) for all other walls, I'd do:
with
lookNorth "The north wall bears a strange inscription.",
lookEast "The east wall seems to be crumbling.",
[lookWall wall;
print_ret (The) wall," is made of large stone blocks.";
];
This would get rid of unneccessary switches for the common cases where you only want a special
description for a single wall, or a single new description for all walls.
John W. Kennedy
> If Carbon and Cocoa are what I think they are, almost the entire
> system may very well be open source, or at least an instance of a
> collection of existing open source projects.
No. Cocoa is the non-Unix API for MacOS X. I don't know how much of
Cocoa's file and process handling is Unixish, but the GUI part is
completely different from X, oriented toward programming in Objective-C,
and using the latest thought in API design.
But Cocoa is also completely different from the API of previous MacOS
versions, so a compatibility feature was needed. Unfortunately,
the old API ("Classic") has fundamental incompatibilities with a
protected system; MacOS X includes the ability to run most Classic
programs, but only by booting a copy of MacOS 9.2 in a virtual machine.
That made a problem for software designers who didn't want to maintain
separate Cocoa and Classic forks, so Carbon was developed as a tertium
quid. Carbon is the same as Classic where possible, and as isomorphic
as possible otherwise, and MacOS 8-9 and MacOS X both have Carbon
layers, so that a Classic program can be easily ported to Carbon, and
then be run either way, though without all the goodies provided by
Cocoa.
In all, then, MacOS X has four API's: Unix, Cocoa, Carbon, and Classic.
All three of the last are proprietary to Apple.
--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood.html
John W. Kennedy
> L. Ross Raszewski wrote:
> [...]
>
>> 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.
>
> Just to be the annoying guy who pulls out the counterexample to the
> counterexample, there was quite a bit of work a few years back in
> semi-triangular wheels (basically, three arcs, rather than three flat
> sides). By staggering the points appropriately, they handle rough
> terrain far better than traditional wheels.
Such things are _possible_, but have terrible vibration problems.
(If they are eccentrically geared so that the carriage does not rock,
then the "wheel's" centers of gravity will, with terrible results unless
the whole structure is rigid and unsprung, which has its own obvious
problems.)
> Not that this is entirely relevant--just that every once in a while,
> advances do happen in the unlikely spots. However, you'll note that
> they started with an *existing* wheel, rather than trying to figure
> out how to reduce the load on the thing they were dragging along...
Actually, I rather fancy they started with an early-60's "Scientific
American" article on constant-width polygons and a mid-60's "Analog"
puzzle story about using such a shape as a roller.
Daniel Barkalow
> The only flaw I see is that there isn't an easy way to cram it into a
> nice, modular library add-on; it needs to (as far as I can tell) be
> hacked into the library, itself.
I managed to come up with a way that didn't involve changing the library
(I think I had sugestions from other people at the time, but I don't
remember who):
Extend "examine" first
* noun=ADirection -> LookDir;
Extend "look" last
* noun=ADirection -> LookDir;
[ LookDirSub i;
if (noun == u_obj)
i = u_desc;
if (noun == n_obj)
i = n_desc;
<and so on...>
if (location.i==0)
return L__M(##Examine,2,noun);
PrintOrRun(location, i);
if (AfterRoutines()==1) rtrue;
];
This messes up the "I only understood you as far as wanting to
look" message, but is otherwise fine even outside of the library.
I should probably put this in a file at some point and upload it to the
archive.
The problem isn't that it's impossible to do cleanly (although it's quite
hard), but that it isn't part of the standard behavior people expect out
of games, although the library message ("You see nothing special about
the <x> wall.") sort of suggests that it should be.
-Iabervon
*This .sig unintentionally changed*
John Colagioia
> John Colagioia wrote:
>> If Carbon and Cocoa are what I think they are, almost the entire
>> system may very well be open source, or at least an instance of a
>> collection of existing open source projects.
> No. Cocoa is the non-Unix API for MacOS X. I don't know how much of
> Cocoa's file and process handling is Unixish, but the GUI part is
> completely different from X, oriented toward programming in Objective-C,
> and using the latest thought in API design.
Objective-C was actually what I was getting at, with respect to
Cocoa. I had heard, at one point, that they were at least
considering using the existing (free, open, whatever) runtimes.
Sounds like that is definitely no longer the case.
> But Cocoa is also completely different
Ah. Thanks for the rundown.
[...]
John W. Kennedy
As far as I know, Objective-C doesn't include a GUI.