World Model and Parser Wish List
James Edward Gray II
want to take it a step further. This time, let's approach it from a
different angle though.
Here's a great quote from the previous disscussion:
Quintin Stone <st...@rps.net> wrote in message news:<Pine.LNX.4.58.04...@yes.rps.net>...
> ...the heart and mind of any IF are the world
> model and parser. And the parser is more than just the tokenization, it's
> also the intelligence to choose the proper matches and do disambiguation.
Okay, let's say I have a mind to build a new IF library or even a
complete system. I can easily learn what's available now by studying
current solutions. However, here's another interesting quote from the
previous thread:
Andrew Plotkin <erky...@eblong.com> wrote in message news:<c3a43a$e5g$1...@reader1.panix.com>...
> I have begun to think that Inform and TADS, with their well-developed
> models -- even TADS 3 -- are only first-generation solutions to the
> problem.
Sounds like people definitely have wish lists and I can't learn what
those are without asking. So...
What would you as IF authors like to see from the second-generation of
IF systems? What would you like out of your world model, that you
don't currently have? Aside from just plain reading English, which
I'm sure we could all wish for, what would you like to see added to
future parsers?
Answers can be simple niceties and additions or radical ways of
rethinking the problem altogether. Gut reactions and first instincts
welcome.
Thanks again for all that you've added to one programmer's continuing
education.
James
P.S. I'll avoid mentioning my language of choice in this thread, if
we can leave the bashing of that choice to the previous thread. :)
Andrew Plotkin
>
> Andrew Plotkin <erky...@eblong.com> wrote in message news:<c3a43a$e5g$1...@reader1.panix.com>...
> > I have begun to think that Inform and TADS, with their well-developed
> > models -- even TADS 3 -- are only first-generation solutions to the
> > problem.
>
> Sounds like people definitely have wish lists and I can't learn what
> those are without asking. So...
>
> What would you as IF authors like to see from the second-generation of
> IF systems? What would you like out of your world model, that you
> don't currently have?
I was thinking of a thread from a few months ago. Search under
"Alternate object oriented programming model". Although in fact I was
saying that object orientation isn't essential at all.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Mike Roberts
> generation of IF systems? What would you like out of your
> world model, that you don't currently have? Aside from just
> plain reading English, which I'm sure we could all wish for,
> what would you like to see added to future parsers?
There are three main areas that I think are worth looking into. I'll warn
you in advance that I think they're all roughly equivalent in difficulty to
full natural language parsing, so these might not be the sorts of things
you're looking for.
First, "drama management" - automatic generation of the sequence of plot
events, adapting to the events of the traversal so far, and automatically
pacing story elements to create the canonical "rising action" effect. The
vision here is that the author writes the story parametrically, defining the
characters, setting, back-story, potential story events, theme, etc., and
the drama manager creates the actual series of events making up the plot.
The goal is for the drama manager to be able to create what we'd think of as
good fiction from these elements: the story must make sense, the climax
should be simultaneously surprising and inevitable to the
reader/player/interactor, the story should be economical (i.e., every
element should contribute directly to the story's "point").
Second, AI for NPC's - not so much natural language parsing for interaction
(although that would be a bonus), but a rich model of motivation, knowledge,
memory, background, psychology. The vision here is similar to the vision
for drama management: authors create characters not by writing a canned
series of responses to stimuli, but by designing the inner mental life of
the characters, and then letting the characters do what comes naturally to
them.
Third, automated narration - mechanical observation of the state of the
world model and a couple of time derivatives of the state (i.e., change in
state from one moment to the next, rate of the change, rate of acceleration
of change, etc.) and machine generation of natural language prose describing
the state and changes to the state. Once again, the vision is that the
author doesn't write canned sequences of text, but designs the narrator
parametrically. Ideally, this would be done by example: the author would
provide a body of text to the system exemplifying the kind of prose the
mechanical narrator should generate, and the system infers the author's
writing style from the example and extrapolates it to produce the actual
narration.
With these three pieces, it should be a relatively simple matter to plug in
a moderately sophisticated world/physics model of the sort that modern
first-person shooters use and get a pretty decent IF system. This is a kind
of Holy Grail IF system, and these pieces are obviously beyond the reach of
current technology. So these probably aren't things to put on your to-do
list, although maybe they'll give you some ideas for areas to explore.
--Mike
mjr underscore at hotmail dot com
Jan Thorsby
"James Edward Gray II" <pe...@grayproductions.net> skrev i melding
news:6fd1fcf5.04031...@posting.google.com...
> What would you as IF authors like to see from the second-generation of
> IF systems? What would you like out of your world model, that you
> don't currently have?
Here is some stuff I would have liked. (I have only written half a game in
Inform, so it might very well have easy solutions to the problems I
describe, which I don't know about. I have found complicated solutions
myself, taking a lot of code.)
1. It would probably have been easier to begin to learn to code if the text
editor, and the compiler and perhaps the manual where all in one program. It
hardly matters much for me now though.
2. An easier way of deciding what happens first. So that you can make a
"before" happen before a "react before" or a "react before" happen before an
"order". And also a way of deciding which "react before" happens first.
Maybe one could put numbers on them, so that number 1 happens before number
2 etc.
Also I think that if a class has a "react before" and an object with that
class has a "react before" the game ignores the "react before" of the class.
Would be useful if there was a way the object could have both "reacts
before"s and one decides which one comes into play first.
3. I am writing a game without "examine". Therefore all stuff must be
described when the player uses "look". One can get a long way with
"describe", but the "describe" attribute dos not work if the object is on,
for instance, a table. I would like another attribute that makes it so that
you can see the description even when the object is on the table. Maybe
there could be a line first saying: "On the table you see:" followed by the
descriptions of all objects on the table. This should also happen if the
player is on the table.
4. I would also have liked a way of deciding it what order the described
items occur in the room description. For instance say a room contains a
lion. The lion will never be in any other rooms. But at some point it will
disappear from the room. So I give it "describe", but the description of the
lion is meant to still feel as part of the room description, even if it isn'
t technically. The problem comes if a player drops an item with "describe".
The description of the item will then come before the description of the
lion. So maybe one could put numbers on the descriptions, so that the game
first describes number 1 and then number 2 and so on.
5. There are a lot of rules that stop a player from doing stuff, like you
can't get off something you are not on. If you try to make a NPC responding
to orders, you have to more or less write all these rules from scratch. It
would be helpful if there existed somewhere the source code to an NPC that
responds to all the orders, by which I mean all the default commands that a
player character responds to, and which follows all the rules that a default
player character do. Then it would be fairly easy to edit the source code
into the NPC one wants.
6. An attribute you can give an object so that it don't appear in a room
description, but don't change the object in any other way. ("Scenery" makes
it so that the object can't be picked up, "concealed" makes it so that the
object can't be picked up by typing "take all".)
Andrew Plotkin
>
> 6. An attribute you can give an object so that it don't appear in a room
> description, but don't change the object in any other way. ("Scenery" makes
> it so that the object can't be picked up, "concealed" makes it so that the
> object can't be picked up by typing "take all".)
You can do this in Inform by giving the object a "describe" property
containing true. (Or [; rtrue; ])
John Roth
> Here, James Edward Gray II <pe...@grayproductions.net> wrote:
> >
> > Andrew Plotkin <erky...@eblong.com> wrote in message
news:<c3a43a$e5g$1...@reader1.panix.com>...
> > > I have begun to think that Inform and TADS, with their well-developed
> > > models -- even TADS 3 -- are only first-generation solutions to the
> > > problem.
> >
> > Sounds like people definitely have wish lists and I can't learn what
> > those are without asking. So...
> >
> > What would you as IF authors like to see from the second-generation of
> > IF systems? What would you like out of your world model, that you
> > don't currently have?
>
> I was thinking of a thread from a few months ago. Search under
> "Alternate object oriented programming model". Although in fact I was
> saying that object orientation isn't essential at all.
Thanks for the reference. I just read it through once, quickly, and I've
got a few observations from a professional software developer's
perspective.
First, some parts of the OO paradigm are very overused; inheritance
and especially multiple inheritance are among them. There are much
better solutions in the OO toolkit to a lot of problems that people try
to use inheritance for. PAWS is a great example of an inappropriate use
of multiple inheritance.
A lot of the thread was a discussion of the difference between saying
"push the button" while treating the button as a switch of some kind, and
while treating the button as an object that can be moved in physical
space.
My initial take on how to solve this one would be to use the
"strategy pattern." A strategy is simply an object that can be bound
to another object to provide answers (that is, strategies.)
We basically have three strategies: "movable", "not movable",
and "pushbutton switch." These three strategies conflict in the
interpretation of the "push" verb.
One general way to disambiguate them is that if one strategy
does something, and another provides a "not capable" message,
then we should pick the interpretation that could succeed,
rather than the one that will surely fail. This doesn't require
a consideration of priorities or anything else; an implementation
strategy that requires us to code up this particular distinction is
simply wrong.
We still have the case where we have both "pushbutton switch"
and "movable." While there's no obvious way of disambiguating
"push the button," there's also no way that a human being would
disambiguate this one reliably either. I'd simply give up with a
message that says something like: "Do you mean to press the
button, or move the button?"
This reminds me somewhat of Inform's attributes, such
as "openable" and "lockable." The difference is that instead
of the logic being in the library (and hence relatively resistant
to change) it's encapsulated in strategy objects that are much
easier to change or replace.
John Roth
Mike Roberts
> One general way to disambiguate them is that if one strategy
> does something, and another provides a "not capable" message,
> then we should pick the interpretation that could succeed,
> rather than the one that will surely fail.
It's not clear you want this precedence ordering in general; you'd want the
opposite for a combination of Openable and Locked. My experience has been
that virtually any generic precedence rule like this will work in some cases
and not in others; it seems best to have the ability to decide how
combinations of attributes/classes/strategies/whatever work per combination.
John Roth
"Mike Roberts" <mjrUND...@hotmail.com> wrote in message
news:ZKn6c.37$L35...@news.oracle.com...
I'm not thinking of it as precedence, I'm thinking of it as
more of looking at the various possible interpretations and
then winnowing out the ones that are clearly unsuitable
in context.
In your example, I would presume that "openable" provides
an interpretation of "open", and "lockable" also provides an
interpretation of "open". Since "lockable" makes no sense
without "openable", that needs to be reflected somewhere.
It doesn't appear to make any difference which order the
two "before_open" routines are executed, as long as they're
both executed until one cancels the action (if it's indeed
canceled.)
The distinction I think I didn't stress was between a
negative result of "this action can't be accomplished
at this time", and "this action makes no sense." Its the
second one that would be ignored if there was another
advice that the action was, indeed, possible.
This is also a place where a good OO design pays
off: the "before_action" needs to return a result object
with the result and the message (if any). Then the verb
routine can decide which (if any) of the result objects
will get it's message printed. If you let the before_action
routine actually print the message, then you're into the
same morass of having to set priorities or whatever
in the object, case by case.
John Roth
John Roth
blog post from Ian Bicking about an attempt to do
a rudimentary engine in Python, and some of the
design goals aimed at dealing with the problems.
http://zephyrfalcon.org/weblog/arch_d7_2004_03_13.html#e523
John Roth
Mike Rozak
> "push the button" while treating the button as a switch of some kind, and
> while treating the button as an object that can be moved in physical
> space.
I thought about this some more after the last thread on OOP issues. I think
there are two issues here:
Issue/stage 1) Text to meaning...
"push the button" (as in depress) vs. "push the button" (as in move) mean
two different things completely. You need some disambiguation call to an
object that asks it "If a user specified "push", did they mean "depress" or
"move"?" This disambgiuation call could also rate the likihood of the
object-in question being the target of the verb... if there were two buttons
in the room, one a doorbell and the other a shirt button, the doorbell would
return a higher score for "depress" than "move", and the doorbell's score
for "depress" would be higher than the shirt button's score for "move".
Likewise, the shirt button's score for "move" would be higher than the its
score for "depress". If two scores are close enough the UI asks the user for
disambiguation.
Issue/stage 2) How an object reacts to a disambiguated (meaningful)
command...
Depending upon the object, and the classes it's built from, some objects
will react differently to different commands (Push_depress vs. push_move).
This could be handled as a standard OOP inheretence tree, or as a more
complex maxtrix that Richard Bartle talks about. (As per previous
discussion.)
It seems to me that Inform, TADs, and Ricard Bartle combine stage 1 and 2
into one operation. (I may be wrong on this.) It is VERY important to
separate these two because:
1) If you want to have NPCs acting on their own in the world their AI should
generate concepts that go directly to stage 2. The output of NPC AI should
NOT go through stage 1.
2) If your IF supports more than one language then stage 1 is language
dependent, while stage 2 is language independent.
--
Mike Rozak
http://www.mxac.com.au
John W. Kennedy
> What would you as IF authors like to see from the second-generation of
> IF systems? What would you like out of your world model, that you
> don't currently have? Aside from just plain reading English, which
> I'm sure we could all wish for, what would you like to see added to
> future parsers?
Multiple sets of children (e.g., "in" and "on"), of course and multiple
parents (e.g., the wooden cup is both an object in the glass case and
something the hotel clerk knows about). (Most obviously done LISPwise
with the use of CONS cells instead of direct chaining.)
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
Sam Denton
I've seen some language somewhere (Javascript perhaps?) where every
object is potentially a class. You can almost do this in Inform, if
you could give an object as a definition of a class:
Object Kitchen with this 1, that 2, theother 3;
Object AnotherKitchen with class Kitchen, that 4;
I.e. AnotherKitchen is just like Kitchen, except /that/ is 4 instead
of 2. I suspect that this would map well to how people actually
create works of i-f:
"You know, it'd be nice to have a cat here. I'll just go back and
recode my dog as a Pet class and derive both the dog and the cat from
it" vs "You know, it'd be nice to have a cat here. I'll just derive
it from the dog I already have."
Sam Denton
> James Edward Gray II wrote:
> > What would you as IF authors like to see from the second-generation of
> > IF systems? What would you like out of your world model, that you
> > don't currently have? Aside from just plain reading English, which
> > I'm sure we could all wish for, what would you like to see added to
> > future parsers?
>
> Multiple sets of children (e.g., "in" and "on"), of course and multiple
> parents (e.g., the wooden cup is both an object in the glass case and
> something the hotel clerk knows about). (Most obviously done LISPwise
> with the use of CONS cells instead of direct chaining.)
The nice thing about the Z-machine is that it is low-level enough that
you can implement things that would be pretty hard to do in other
languages. Thus:
The Platypus library has already accomplished the former goal, while
in the standard library you can grit your teeth and implement an
object as a set of components:
Object ChestOfDrawers;
Object -> OnTheChestOfDrawers;
Object -> InTheChestOfDrawers;
Object -> UnderTheChestOfDrawers;
Object -> BehindTheChestOfDrawers;
et cetera
(See exercise 103 in DM4 for something simpler but similar.)
The latter goal is a bit trickier, but I've considered ways of doing
it in Inform, including writing 'malloc' and 'free' routines in Inform
that use a big array for dynamic memory. Then I realized that, at
least where 'knowlege' is ocncerned, as long as there are a reasonable
number of NPCs then you could use bitmaps to represent who knows which
facts.
Uli Kusterer
deja...@email.com (Sam Denton) wrote:
> I've seen some language somewhere (Javascript perhaps?) where every
> object is potentially a class.
TADS works like that.
Cheers,
-- Uli
http://www.zathras.de
Daniel Barkalow
> I've received some great insight from a previous thread here, so I
> want to take it a step further. This time, let's approach it from a
> different angle though.
>
> Here's a great quote from the previous disscussion:
>
> Quintin Stone <st...@rps.net> wrote in message news:<Pine.LNX.4.58.04...@yes.rps.net>...
> > ...the heart and mind of any IF are the world
> > model and parser. And the parser is more than just the tokenization, it's
> > also the intelligence to choose the proper matches and do disambiguation.
>
> Okay, let's say I have a mind to build a new IF library or even a
> complete system. I can easily learn what's available now by studying
> current solutions. However, here's another interesting quote from the
> previous thread:
>
> Andrew Plotkin <erky...@eblong.com> wrote in message news:<c3a43a$e5g$1...@reader1.panix.com>...
> > I have begun to think that Inform and TADS, with their well-developed
> > models -- even TADS 3 -- are only first-generation solutions to the
> > problem.
>
> Sounds like people definitely have wish lists and I can't learn what
> those are without asking. So...
>
> What would you as IF authors like to see from the second-generation of
> IF systems? What would you like out of your world model, that you
> don't currently have?
The ability to write chains of general dependancies, which can be
overriden in particular cases. That is, there are a number of verbs which
involve touching objects as normally interpretted. It would be convenient
to be able to write code for "touch" which is used automatically as a
first step in carrying out these actions. But there are also objects which
may not require touch to do some verbs, and some objects for which the
verbs mean totally different actions.
It would be useful if there were language syntax support for intercepting
and overriding any of the steps in a action implementation. The language
would act like there was an inherited series of steps, and each step could
be left alone or modified as needed. E.g.:
Class general
action read {
show_contents:
print "There is no writing on #self#."
}
Class book extends general
action read {
prepare:
open();
parent.show_contents;
}
Class spellbook extends book
action read {
show_contents:
print "There are many interesting spells to read, such as...";
},
action open {
parent.prepare;
if (actor not protected) {
zap(actor);
return;
}
parent.perform;
}
That is, to read a book, you must open it. Opening the spellbook requires
the normal start to opening something (including, perhaps, picking it up),
then has a special effect, then does the normal thing. Reading a generic
object is uninformative, but the spellbook actually has text.
> Aside from just plain reading English, which I'm sure we could all wish
> for, what would you like to see added to future parsers?
I'd actually like substantial text generation support. Platypus has the
start of this, but it would be good to extend (and use in a more standard
library). The idea is that the library will keep track of pronouns and
point of view, and modify the text it is producing as appropriate for this
context. So you could have the library print out, at no particular time:
"The queen looks upon you coldly."
But, if the player happens to have just typed a command which generated:
"The queen is seated on her throne, holding court. The people look to her
for support."
The library will print, instead of the original line:
"She looks upon you coldly."
For that matter, the parser should be following the output, so that, even
if the player didn't refer to the queen, after the library prints:
"The queen looks upon you coldly."
The player can type "EXAMINE HER". Of course, if the player has typed a
compound command, all of the pronouns are determined by the commands.
I'd also like a "USE" verb that does what both the player and the author
expect, thereby neither annoying the player nor giving away puzzles.
-Iabervon
*This .sig unintentionally changed*
Ben Rudiak-Gould
<mjrUND...@hotmail.com> wrote:
>First, "drama management" - automatic generation of the sequence of plot
>events [...]
>
>Second, AI for NPC's [...] authors create characters not by writing a canned
>series of responses to stimuli, but by designing the inner mental life of
>the characters, and then letting the characters do what comes naturally to
>them. [...]
>
>Third, automated narration [...] machine generation of natural language
>prose describing the state and changes to the state. [...]
Every artist's fantasy:
http://www.angryflower.com/___.gif
But seriously, I'm not sure I agree that this is the right ideal to
strive for in IF library design. Right now the computer's role in IF
is largely limited to choosing *when* to display a particular block of
human-written prose. When the computer pieces together a sentence it's
for administrative purposes like listing inventory or asking
disambiguation questions; as a player, I parse this mechanically-
generated output in a mechanical way, and don't think of it as a part
of the story I'm exploring. I think you're suggesting that the
computer participate in writing the story proper, and this strikes me
as an entirely new art form, not a technological advance in IF.
I'm not even convinced that improving the existing world models is
necessarily a good idea. Even with present technology, good world
models are often at odds with good fiction -- witness inventory limits
and battery-powered lanterns that go dead, or for that matter
forward/left/right instead of compass directions. Any time the world
model becomes more sophisticated there's a danger that it'll just make
games more fiddly (less predictable, less straightforward) without
adding anything to the reading or playing experience.
Nor is it clear to me that full natural-language parsing is a sensible
goal, except perhaps for NPC interaction. Most of my commands to the
parser tend to look like "i" or "se" or "x green". I'm not thinking in
English when I type these; nor should I be, because I don't think in
English when interacting with the real world. I think a game that
forced me to type in complete sentences (as _Winchester's Nightmare_
does) would tend to reduce my sense of immersion, not increase it. If
anything, I'd like to see future parser research move away from
natural-language recognition, though I have no idea what could
effectively replace it.
-- Ben
Kent Tessman
news:3c863a7a.04031...@posting.google.com...
> I've seen some language somewhere (Javascript perhaps?) where every
> object is potentially a class.
As in Hugo. And, I'm told, TADS.
> I suspect that this would map well to how people actually
> create works of i-f:
Yes, works quite well.
James Edward Gray II
I've written a MUD that functions along the lines of what this post
mentions.
In the MUD, admins can "attach" actions to objects. Then, when a
command is entered, attached actions are given the chance handle it.
First action to claim it, handles it. Player actions are searched
first, then actions provided by the current room, then actions
provided by things in the current room, then actions provided by
player inventory.
My parser isn't as significant as most IF models. Actually, this
structure means there isn't really much of a parser. Each action
determines whether or not it wants that line, on its own. Many simple
actions just hit the line with a regex to make their decision, but
complex actions can have a subroutine that does their parsing.
The MUD itself provides many services to ease this process, the most
notable of which is probably the targeting system. If some player
wants to use a targeted say/tell/whatever command for example, the
first thing the action code would have to do is probably acquire the
MUD's object for the target by name. Once you isolate the name (often
just a capture of the regex that accepted the command), you can hand
it off to the MUD and let it do the legwork. The system supports
disambiguation and "not found" type error handling, printing the
appropriate messages to the player and returning no target object.
I realize this system has some inherent flaws. Primarily, getting to
lower level commands, if the top commands swallow the input.
Generally this is less of a problem than it sounds, since the high
level commands are the defaults to support things like say, movement,
etc. and the low level commands are generally much more custom. I
mostly ignore this issue in fact, with a few well documented
conventions. (To date though, I am the sole developer. It could get
more complicated, if that changed.)
Please remember that I'm an IF newbie. I'm sure this all sounds crazy
simple against what your interpreters do for free. It is. Examples
of this are plentiful. When my MUD asks you if you ment Bob or Brain,
after you only fed the targeting system a b (it has auto-complete),
you can't answer with the name only. You must reissue the whole
command with a less ambiguous target. Likewise, it doesn't understand
things like "it". (As a side note, I have ideas about possibly fixing
these issues, now that I've seen how cool your systems are. I would
probably do this by inserting an object at the top of the chain that
just listens for things like clarifications to ambiguous statements.
"it" and friends would be a touch trickier, but I'm sure I could come
up with something, given time.)
The point of all this rambling though is simple. I love my "attached"
action system and in practice it works surprisingly well. I only have
two player classes, the basic player and the admin subclass. I only
have one room class. "Things" are slightly more complicated, but not
overly so. There's a basic "thing" class, an NPC subclass, a
container subclass, a weapon subclass, etc. Attached actions and
various properties you can set on these objects handle the rest of the
needed customization.
In short, I agree with John that inheritance is over-used.
James
Andrew Plotkin
> > A lot of the thread was a discussion of the difference between saying
> > "push the button" while treating the button as a switch of some kind, and
> > while treating the button as an object that can be moved in physical
> > space.
>
> I thought about this some more after the last thread on OOP issues. I think
> there are two issues here:
>
> Issue/stage 1) Text to meaning...
>
> "push the button" (as in depress) vs. "push the button" (as in move) mean
> two different things completely. You need some disambiguation call to an
> object that asks it "If a user specified "push", did they mean "depress" or
>
> Issue/stage 2) How an object reacts to a disambiguated (meaningful)
> command...
>
> Depending upon the object, and the classes it's built from, some objects
> will react differently to different commands (Push_depress vs. push_move).
> This could be handled as a standard OOP inheretence tree, or as a more
> complex maxtrix that Richard Bartle talks about.
You are correct that these are two issues. However, I find that I
don't run into problems of the first part when I'm creating IF. I
think this is because it's pretty easy to divide up functionality
among game objects so that verbs don't conflict. You can *avoid*
creating an object which can sensibly be both pressed and shoved
around the room. This doesn't compromise your freedom of game design;
you just put the button on a pedestal (or whatever) and make it clear
which nouns refer to which parts of the assemblage.
On the other hand, stage 2 causes me lots of trouble. There are many
conditions that can affect the outcome of a particular logical action
such as "press button". Some of them (i.e., darkness) have nothing to
do with the button per se.
These can't be compared by the "which will be successful?" rule that
John was talking about, because they are aiming for particular kinds
of failure as often as particular kinds of success. You can't read a
book in the dark. That's the point of the darkness rule, and it has to
take precedence over successful "read" outcomes.
Andrew Plotkin
> James Edward Gray II wrote:
> > What would you as IF authors like to see from the second-generation of
> > IF systems? What would you like out of your world model, that you
> > don't currently have? Aside from just plain reading English, which
> > I'm sure we could all wish for, what would you like to see added to
> > future parsers?
>
> Multiple sets of children (e.g., "in" and "on"), of course
So, what do you mean by this?
An Inform game has to cope with "the contents of an object" in about
three different contexts:
1: When printing a room description, or an inventory listing, the
library standardly prints out the contents along with the container.
2: When undertaking an action like "put in", "put on", or "take" (for
an object already in/on something), the library applies standard rules
to determine the outcome of the action.
3: The game code may want to test containership ("x in y"), or iterate
over contents ("objectloop x in y"). These are done for game-specific
reasons.
So you want an object which has more than one contents list. The
canonical example is a container/supporter, like a filing cabinet with
crap piled on top. (Every filing cabinet has crap piled on top,
right?)
For (1), the library probably could not print out both sets of
contents in a standard way which would satisfy anyone. On the hand,
so what. The default behavior can be to print just one set of contents
(say, the "supported" list); the game author can come in and customize
the Look and Search actions.
For (2), you probably want full support for the standard IF verbs,
dealing with both "contained" and "supported" objects.
For (3), you need language primitives that give you full control. It's
not obvious what those would look like. Perhaps have a specifying
extra argument:
if ChildOf(y, x, ##Contains)...
if ChildOf(y, x, ##Supports)...
objectloop (ChildOf(y, x, ##Contains)) { ... }
MoveTo(x, y, ##Supports);
Note that the container/supporter isn't the only case. Inform also
uses the object tree to express objects with sub-parts. So you might
want a container/multipart object, or a supporter/multipart, or an
object with all three kinds of contents.
It's also reasonable to consider an object which contains more than
one sublist in the *same* sense. Say, a backpack with several internal
pockets. (The notation I proposed a few lines up doesn't handle that
case.)
An alternate approach is to stick with a simple object tree, but make
the parts hierarchical. The filing cabinet contains two subparts,
"inside" and "surface", which are a container and a supporter
respectively. The backpack contains several subparts, each of which is
a container.
Inform doesn't allow this (currently), because the contents listing
(1) only looks at the top-level object; and the verbs (2) choke when
trying to move "through" the upper (subpart) layer. However, a library
extension to fix those problems wouldn't be too difficult.
> multiple parents (e.g., the wooden cup is both an object in the
> glass case and something the hotel clerk knows about).
Ah, interesting example. Here you want to leave the standard object
tree behavior in place (1 and 2), and you also want (3) to be
unchanged by default. But you also want a custom set of primitives
which express a completely separate object-tree relationship.
My alternate approach doesn't cope with this, obviously.
Inform already has a crude form of multiple-parents: the "found_in"
property. It's nasty and impossible to generalize. Certainly be worth
folding it into a general multiparent model, if there was one.
Mike Roberts
[about my suggestion that automatic drama management, NPC AI,
and machine-generated narration form a sort of holy grail of IF]
Let me start out by saying that I actually pretty much share your position
on all of this. I was talking blue-sky, since the original poster seemed to
be in that mode; I figured other people would provide the laundry lists of
ways to improve react_before by adding a third possible return value and the
like, so I just wanted to throw out some ideas about where I see the hard
limits that characterize the present generation of technology. I don't have
any idea where to begin with any of these problems, which all look
AI-complete to me.
> But seriously, I'm not sure I agree that this is the right ideal to
> strive for in IF library design. [...] I think you're suggesting that
> the computer participate in writing the story proper, and this strikes
> me as an entirely new art form, not a technological advance in IF.
I'd call it both. I'm not sure it's even possible in principle; I've
written about my skepticism about the feasibility of creating fiction this
way here before (see, for example, the past thread "the unending game... is
winning necessary?"), irrespective of technology. If it were possible,
though, I wouldn't necessarily consider it the computer writing the story;
the grand vision, stated more completely by David Graves and others ten or
fifteen years ago, is that the author and player collaboratively write the
story, with the computer mediating based on the author's intent (as
expressed through the parameterized story base) and the player's (as
expressed through actions in play). The vision is that the computer writes
the story the author would have written given the player's input, so in that
sense it's still the author's story.
But in any case, it's one possible kind of IF. The fully deterministic,
pre-destined variety possible today is another kind, and for this kind, a
"holy grail" system like this is not the logical extreme.
> I'm not even convinced that improving the existing world models
> is necessarily a good idea. Even with present technology, good
> world models are often at odds with good fiction -- witness
> inventory limits and battery-powered lanterns that go dead, or
> for that matter forward/left/right instead of compass directions.
> Any time the world model becomes more sophisticated there's
> a danger that it'll just make games more fiddly [...]
I'm in full agreement with you about the badness of those things, but I
wouldn't call them sophistication of the world model - those are examples of
real-world fidelity, which is an orthogonal axis. An inventory limit isn't
a complication of the world model; it's just an extra rule that can be
applied, or not, to models of varying sophistication. But there's no doubt
that pursuing real-world fidelity is often misguided.
> Nor is it clear to me that full natural-language parsing is a
> sensible goal, except perhaps for NPC interaction.
Well, I think most people would see it as a big plus, if it were complete.
That is, if you really could type in arbitrary natural-language commands and
have them interpreted as well as a human would interpret them, I can't
imagine any way that could detract from the experience.
> Most of my commands to the parser tend to look like "i" or
> "se" or "x green".
But a human (who's aware of the conventions of the game) reading those
commands would know exactly what you mean, so by my definition a full NLP
computer parser would as well. So NLP wouldn't detract from your ability to
enter abbreviations or conventional commands.
> If anything, I'd like to see future parser research move away
> from natural-language recognition, though I have no idea what
> could effectively replace it.
Agreed; my own attitude about it is that partial NLP solutions are worse
than nothing, because they frustrate people by over-promising. The
mainstream gaming world has solved this problem by switching away from text
interfaces entirely, right? The text IF community has kind of grudgingly
settled into the notion that the solution is convention (i.e., players and
authors agree on a command set that everyone knows), but there's still a
strong instinct to create parsers that are as flexible as possible at
handling natural-language-like input.
Michael Chapman Martin
> 1. It would probably have been easier to begin to learn to code if the text
> editor, and the compiler and perhaps the manual where all in one program. It
> hardly matters much for me now though.
That's an interface issue; one can write a program to invoke compilers,
PDF viewers, interpreters, etc. without much trouble. There's at least one
for Inform already (called JIF, I believe.)
I only found out about that one by chance on the newsgroup though; are IDEs
collected or linked to at any of the standard sites?
Daniel Barkalow
> On Thu, 18 Mar 2004 11:21:35 -0800, "Mike Roberts"
> <mjrUND...@hotmail.com> wrote:
>
> >First, "drama management" - automatic generation of the sequence of plot
> >events [...]
> >
> >Second, AI for NPC's [...] authors create characters not by writing a canned
> >series of responses to stimuli, but by designing the inner mental life of
> >the characters, and then letting the characters do what comes naturally to
> >them. [...]
> >
> >Third, automated narration [...] machine generation of natural language
> >prose describing the state and changes to the state. [...]
>
> Every artist's fantasy:
>
> http://www.angryflower.com/___.gif
>
> But seriously, I'm not sure I agree that this is the right ideal to
> strive for in IF library design. Right now the computer's role in IF
> is largely limited to choosing *when* to display a particular block of
> human-written prose. When the computer pieces together a sentence it's
> for administrative purposes like listing inventory or asking
> disambiguation questions; as a player, I parse this mechanically-
> generated output in a mechanical way, and don't think of it as a part
> of the story I'm exploring. I think you're suggesting that the
> computer participate in writing the story proper, and this strikes me
> as an entirely new art form, not a technological advance in IF.
There's certainly the potential for the computer to participate in
generating text (and, particularly, formatting), without having any of the
content generated by the computer. I think it would be good if the
computer could modify the text to improve the flow of adjacent bits of the
authors text which are only put together at runtime due to the particular
interaction with the player.
I think it's a very interesting idea to have the computer actually
generate the story, but that's a very different thing; I think it is
actually desireable that the game *not* respond to all of the player's
attempts to change the outcome of the story, as that makes the experience
so different for different players as to no longer be something you can
really share.
> I'm not even convinced that improving the existing world models is
> necessarily a good idea. Even with present technology, good world
> models are often at odds with good fiction -- witness inventory limits
> and battery-powered lanterns that go dead, or for that matter
> forward/left/right instead of compass directions. Any time the world
> model becomes more sophisticated there's a danger that it'll just make
> games more fiddly (less predictable, less straightforward) without
> adding anything to the reading or playing experience.
I don't think an entirely realistic world model would be good for
fiction. On the other hand, a world model could be very good in terms of
handling interactions between the constraints the author imposes in terms
of the situation and the things the player can do. A good world model
would allow the author to focus on the story and have the nitpicky details
that beta-testers find come out right automatically. It's not a question
of making the model world work like the real world works, but of making
the model world work like the author expects it to.
> Nor is it clear to me that full natural-language parsing is a sensible
> goal, except perhaps for NPC interaction. Most of my commands to the
> parser tend to look like "i" or "se" or "x green". I'm not thinking in
> English when I type these; nor should I be, because I don't think in
> English when interacting with the real world. I think a game that
> forced me to type in complete sentences (as _Winchester's Nightmare_
> does) would tend to reduce my sense of immersion, not increase it. If
> anything, I'd like to see future parser research move away from
> natural-language recognition, though I have no idea what could
> effectively replace it.
There are two problems with natural language: (1) it's hard for humans to
produce (which may be surprising, but is the reason that there are
professional writers); (2) it's hard to process. We get around (1) by
accepting all sorts of lousy text and shorthands as input. We could
actually work harder on (2), though, so that anything that people actually
type is understood. That is, we would still rely on convention, but new
players wouldn't have to know the conventions; they could type longer
things which would automatically work just as well.
Adam Thornton
Daniel Barkalow <iabe...@iabervon.org> wrote:
>I don't think an entirely realistic world model would be good for
>fiction.
Simulationism cries!
Dramaturgism cheers!
Adam
Roger Firth
news:c3fu35$23s$1...@news.Stanford.EDU...
http://www.firthworks.com/roger/editors/index.html
Cheers, Roger
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
You'll find my Cloak of Darkness, Parsifal, Informary
and more at http://www.firthworks.com/roger/
Daniel Barkalow
> Here, Mike Rozak <Mike...@bigpond.com> wrote:
> >
> > I thought about this some more after the last thread on OOP issues. I think
> > there are two issues here:
> >
> > Issue/stage 1) Text to meaning...
> >
> > "push the button" (as in depress) vs. "push the button" (as in move) mean
> > two different things completely. You need some disambiguation call to an
> > object that asks it "If a user specified "push", did they mean "depress" or
> > "move"?" [...]
>
> You are correct that these are two issues. However, I find that I
> don't run into problems of the first part when I'm creating IF. I
> think this is because it's pretty easy to divide up functionality
> among game objects so that verbs don't conflict. You can *avoid*
> creating an object which can sensibly be both pressed and shoved
> around the room. This doesn't compromise your freedom of game design;
> you just put the button on a pedestal (or whatever) and make it clear
> which nouns refer to which parts of the assemblage.
The issue here, for me, is that, if the library is implementing the
prerequisites for the specified action, it needs to know what the
player is actually supposed to be doing, rather than merely what the verb
is. For example, "push the dresser" requires the object not to be held,
while, er, "push the drugs" requires the object to be held. If the library
is handling automatically taking things, it will need to be able to tell
the difference.
Andrew Plotkin
I see what you mean. Yes, a disambiguation call to the object is
needed here (with the action as a parameter).
But the current models handle that. It isn't the sort of thing that
makes me want to redesign the world model; nor is it a problem solved
by the idea John Roth was talking about in the post you replied it.
(I hope I'm remembering the threading correctly. :)
John Roth
Well, maybe. If we get into this example, both usages of
"push" are similar when we realize that "push the drugs" is
simply an example of typical sales lingo (push the product
out the door...) and that is a very close metaphor to
physically pushing a physical object around the room.
Of course, I'm not aware of any game system that is capable
of actually recognizing and exploiting the similarity here.
The interesting thing is that the word "push" doesn't exist
in isolation. In the one case, it's used with physical objects,
in the other it's used in a sales scenario.
It's a notion that's from some AI language understanding
work that tried to identify scenarios and then use them
to interpret the actual words. At this point I have no idea
whether it's possible, or even worth while, to pursue this notion.
John Roth
Kevin Forchione
<snip>
> An alternate approach is to stick with a simple object tree, but make
> the parts hierarchical. The filing cabinet contains two subparts,
> "inside" and "surface", which are a container and a supporter
> respectively. The backpack contains several subparts, each of which is
> a container.
>
> Inform doesn't allow this (currently), because the contents listing
> (1) only looks at the top-level object; and the verbs (2) choke when
> trying to move "through" the upper (subpart) layer. However, a library
> extension to fix those problems wouldn't be too difficult.
TADS has been wrestling with this concept as well. The issues are the same,
scope, disambiguation, and redirection. TADS 3 has a specialized class for
this complex containment, aptly called ComplexContainer. It allows for a
subContainer, subSurface, subUnderside, and subRear. An example of a washing
machine with objects both inside and on top is shown below:
+ washingMachine: ComplexContainer 'washing machine' 'washing machine'
subContainer: ComplexComponent, Container { etc }
subSurface: ComplexComponent, Surface { etc }
;
++ Thing 'big cotton blanket' 'blanket'
subLocation = &subContainer
;
++ Container 'laundry basket' 'laundry basket'
subLocation = &subSurface
;
Also notice that the notation becomes somewhat specialized. The cotton
blanket and laundry basket get placed into the washing machine's contents
list through the ++ notation, and then further processing uses the
subLocation property of these objects to locate them in their appropriate
subSurface/subContainer.
This class provides contents listing and verb redirection mechanisms as
well. So we can define a washing machine with a surface and an inside, but
we can't use the class for say, a chest of drawers. In those kinds of cases,
where the complex object consists of multiples of the same kind of class
then things get a little hairy. It might be possible to combine the
ComplexClass with one of the "collective" classes, but I've not tried this.
> > multiple parents (e.g., the wooden cup is both an object in the
> > glass case and something the hotel clerk knows about).
>
> Ah, interesting example. Here you want to leave the standard object
> tree behavior in place (1 and 2), and you also want (3) to be
> unchanged by default. But you also want a custom set of primitives
> which express a completely separate object-tree relationship.
In this case actor possessive knowledge can be represented by a hash table
containing all the objects that the actor might "claim" as his. The parser
would then check the hash table to reduce the candidate list to only those
objects that match the actor's possessive knowledge. <<ask clerk about his
cup>> might then produce curious responses, based on whether (a) the cup(s)
in question is in scope; (b) if no cup(s) belonging to the clerk are in
scope, yet cup(s) are in scope; (c) or whether no cup(s) are in scope. The
most interesting case being (b), where a possible response might be, "That
cup, sir? That is not mine."
Of course possession, being 9/10's of the law, is probably as fraught with
complications in simulation as it is in real life.
--Kevin