Futzing with continuous substances
Andrew Plotkin
evil water/fire/rope problem, in an ideal world where parser code was
easy to write.
I decided that the answer was to make object properties accessible to
the parser. So that if there's water in the bucket, the player can say
refer to "the water in the bucket". Always. And if the water in the
bucket is hot, then "hot water" should work too.
Then I went ahead and implemented it. Only I wasn't really interested
in futzing with containers, so instead of water, I made it lumps of
clay. And piles of ball bearings.
This is purely an experimental model. It has rough edges; it has ugly
spots; it has bugs. (Type BUGS for an incomplete list of bugs.) I'm
not really planning to fix it, or update it any more. However, if
anyone wants to play with it, feel free. Steal code. Stick it in a
game.
<http://www.eblong.com/zarf/tmp/massnoun.z5> for game file,
<http://www.eblong.com/zarf/tmp/massnoun.inf> for source.
(I will copy the files to the Archive soon.)
The ABOUT text from the game is pasted below, so that I don't have to
retype a perfectly good explanation. :)
-----------
My theory is this: there is usually a sensible way to divide up the
substance, such that each unit is an IF-style "thing". That is, the
player will want to refer to one unit per command. (I should say, the
player will want to refer to one unit per noun phrase. "Put X in Y" is
two noun phrases.) There may be water in the bottle, a puddle of water
on the floor, and a lake nearby. Each of those should be one IF
object.
That much is not controversial. The reason this falls apart in
implementation is this: the player can't figure out how to refer to a
particular IF object. They're all called "water".
This problem should be solvable. The whole point of having several
units of a substance in a game -- presumably! -- is that they differ
in some way. Location, form, quantity, temperature, color. The various
bits of water have properties, and these properties distinguish them.
So what we want is a system that will (1) make it clear to the player
what properties a unit has, and (2) allow the player to refer to any
of those properties. And also (3) if two units are truly identical,
distinguish them anyway as "first", "second", etc. so that the player
can still refer to them.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
RootShell
> I got into an email discussion about how IF *could* deal with the big
> evil water/fire/rope problem, in an ideal world where parser code was
> easy to write.
>
> I decided that the answer was to make object properties accessible to
> the parser. So that if there's water in the bucket, the player can say
> refer to "the water in the bucket". Always. And if the water in the
> bucket is hot, then "hot water" should work too.
>
Maybe this a good issue for the new version of *that* IF progamming
language that everyone has been talking/asking about, which we cant say
the name of, so that we do not pressure the author which we cant say
it's name either ;)
I suppose that genereal IF programming languages should evolve and this
seems to me a good direction to follow, to include/solve that 'big evil'
water/fire/rope problem.
While I never coded a game myself (maybe when I do a little more reading
on the subject) I cant say for real how this can be solved, but i guess
that a lot of things were already implemented (since the first version
of *that* IF programming language) due to the need of the programmers,
so why not this one? Of course, there could be a issue that this
particular problem should be handled by the programmers code.
Maybe that's the justification for the integer increase in the version
of *the* IF progamming language mentioned above, that we cant really say
the name, nor the author's name, so that we dont put too much pressure
on it/him :)
Well, just my two cents anyway, which can be completly disregarded if
disagreed.
Kind Regards,
RootShell
--
RootShell, Lisbon, Portugal, Europe, Earth ;)
To protect against spam, the address in the "From:" header is not valid.
In any case, you should reply to the group so that everyone can benefit.
If you must send me a private email, use -> RootShell AT netcabo DOT pt
samwyse
> I got into an email discussion about how IF *could* deal with the big
> evil water/fire/rope problem, in an ideal world where parser code was
> easy to write.
>
> I decided that the answer was to make object properties accessible to
> the parser. So that if there's water in the bucket, the player can say
> refer to "the water in the bucket". Always. And if the water in the
> bucket is hot, then "hot water" should work too.
The standard parser already knows about a few, hard-coded, properties.
The same code that handles the TWO in TAKE TWO CANDLES also understands
LIT, as in TAKE THE LIT CANDLES. The problem is that the word LIT is
hardcoded in the parser to mean objects with the 'light' property set,
there's no way to make HOT work similarly.
I *still* haven't gotten around to coding anything with the Platypus
library, but for some reason I re-read the documentation every six
months or so. Platypus has generalized the above code, so an author can
add additional descriptors to the parser, thus providing a way to have
'hot' objects. (According to the docs, LIT isn't recognized, but EMPTY,
as in PUT THE MONEY IN THE EMPTY BAG, is). See this page for details:
http://homepage.ntlworld.com/elvwood/InteractiveFiction/Platypus/Summary.html#Parsing
One thing to note is that Playtus is using a single ParseDescriptor
entry point. To ease the writing of extentions, anyone adding something
similar to the standard Inform library would want to provide a
ext_parse_descriptor method for use by extension objects.
Another issue to consider is that there's no standard way to display
descriptors, i.e. no way for code like this:
"You pick up ",(the_adj)obj, ".";
to produce output like this:
You pick up the hot potato.
I'd like to see a PrintDescriptor entry point that, for instance, prints
'hot' if an an object is hot. Ideally, (the_adj) and (The_adj) would
function like (the) and (The), but that would require compiler treaks.
Andrew Plotkin
> Andrew Plotkin wrote:
> > I got into an email discussion about how IF *could* deal with the big
> > evil water/fire/rope problem, in an ideal world where parser code was
> > easy to write.
> >
> > I decided that the answer was to make object properties accessible to
> > the parser. So that if there's water in the bucket, the player can say
> > refer to "the water in the bucket". Always. And if the water in the
> > bucket is hot, then "hot water" should work too.
> >
> [snip]
>
> Maybe this a good issue for the new version of *that* IF progamming
> language that everyone has been talking/asking about, which we cant say
> the name of, so that we do not pressure the author which we cant say
> it's name either ;)
Maybe. But I'm not working on that. That's why I wrote some Inform 6
code for people to look at, play around with, and maybe make use of.
What did you think of it?
Andrew Plotkin
> On or about 4/19/2005 10:02 PM, Andrew Plotkin did proclaim:
> > I got into an email discussion about how IF *could* deal with the big
> > evil water/fire/rope problem, in an ideal world where parser code was
> > easy to write.
> >
> > I decided that the answer was to make object properties accessible to
> > the parser. So that if there's water in the bucket, the player can say
> > refer to "the water in the bucket". Always. And if the water in the
> > bucket is hot, then "hot water" should work too.
>
> The standard parser already knows about a few, hard-coded, properties.
> The same code that handles the TWO in TAKE TWO CANDLES also understands
> LIT, as in TAKE THE LIT CANDLES. The problem is that the word LIT is
> hardcoded in the parser to mean objects with the 'light' property set,
> there's no way to make HOT work similarly.
You are entirely right. I've found (when writing actual games) that
the library's hardcoded handling is worse than useless -- it's never
what I want. I tried to set up massnoun.inf so that the properties are
defined game-side. (I had partial success.)
> I *still* haven't gotten around to coding anything with the Platypus
> library, but for some reason I re-read the documentation every six
> months or so. Platypus has generalized the above code, so an author can
> add additional descriptors to the parser, thus providing a way to have
> 'hot' objects. (According to the docs, LIT isn't recognized, but EMPTY,
> as in PUT THE MONEY IN THE EMPTY BAG, is).
That's part of it. I had to work harder to get "six ounces of gold" to
behave right. I'm assuming that measured quantities are going to be a
common (though not universal) need in games that use continuous
substances.
> [...]
> Another issue to consider is that there's no standard way to display
> descriptors, i.e. no way for code like this:
> "You pick up ",(the_adj)obj, ".";
> to produce output like this:
> You pick up the hot potato.
This half of the problem is just as critical as the parsing half. The
player can't type a meaningful command unless he knows what
distinguishes the various instances in scope.
(One feature which I did not get around to coding: enhanced object
names at disambiguation time. "Which onion do you mean, the onion on
the table, the onion you're holding, the onion in the chest, or one of
the onions on the floor?" Which would be valuable with or without the
ordinal system. Actually, it might make the ordinal system redundant.)
Ross Presser
>take 10000 ball bearings
(extracing ten thousand metal items from the bucketful of ball bearings)
"You scoop 10000 ball bearings from the bucket."
Boy, I'm strong...
Andrew Plotkin
It's only 62 pounds. Peanuts.
Pile a few of those together, however, and you'll run into some
impressive overflow bugs. (16-bit variables, and I don't do any bounds
checking.)
Daryl McCullough
A problem that I've had in the past is how to deal with a large
collection of identical thingys. For example, a bag of potato
chips. The easiest way to handle it is not to represent an individual
chip at all, but to simply code the bag with a "number" property that
returns the number of chips left. That works fine if the player is
only allowed to eat chips. But if the player gets creative, and wants
to drop chips, Hansel-and-Gretel style, to mark where he has been,
then you have to actually make up objects to represent the chips.
That seems like overkill for a potato chip.
(Or alternatively, I guess you could just give *every* location a
"chip-number" property saying how many chips are in that location).
--
Daryl McCullough
Ithaca, NY
RootShell
Andrew
I left your post as you posted, so that you could see that you [snipped]
the part were I mentioned that i never got around to code a game.
Im still in the learning phase of it, reading books (IDM4, IBG, etc).
I guess the new version will be the one i will eventually have to deal
with, so maybe i'll start testing/checking/using other coders libraries
then.
But despite the fact that i havent programmed anything yet, doesnt mean
that i dont give value to hard work people have sharing/coding libraries
that extend the language.
I really just wanted to say that it would be a good feature for the new
version.
Hope you dont be upset that my post wasnt really about giving you
feedback on your code. :)
Best Regards,
Andrew Plotkin
> This is sortof related.
>
> A problem that I've had in the past is how to deal with a large
> collection of identical thingys. For example, a bag of potato
> chips. The easiest way to handle it is not to represent an individual
> chip at all, but to simply code the bag with a "number" property that
> returns the number of chips left. That works fine if the player is
> only allowed to eat chips. But if the player gets creative, and wants
> to drop chips, Hansel-and-Gretel style, to mark where he has been,
> then you have to actually make up objects to represent the chips.
> That seems like overkill for a potato chip.
This is exactly how I handled the ball bearings. It may be overkill,
but it works.
(Although I forgot to implement "drop one ball bearing". I could add
it, it would only be a few lines of code.)
> (Or alternatively, I guess you could just give *every* location a
> "chip-number" property saying how many chips are in that location).
That could be done, but it's easiest in Inform to represent each
player-referrable object as one Z-code object. The fact that you need
to "allocate" sufficient objects at compile time is unlikely to kill
you. Although you may wind up needing some auto-coalescing code. (That
is, if the player puts two potato chips in the same room, or
container, they are replaced by a single object representing two chips.)
Andrew Plotkin
> Andrew Plotkin wrote:
> > Here, RootShell <spam@this> wrote:
> >
> >>Andrew Plotkin wrote:
> >
> > Maybe. But I'm not working on that. That's why I wrote some Inform 6
> > code for people to look at, play around with, and maybe make use of.
> >
> > What did you think of it?
>
> the part were I mentioned that i never got around to code a game.
I'm sorry -- I meant it as an open question, of both game authors and
game players. Is the test game comfortable to play in? Can you express
commands that do what you'd want to do in a real game with fluids?
J. J. Guest
> (One feature which I did not get around to coding: enhanced object
> names at disambiguation time. "Which onion do you mean, the onion on
> the table, the onion you're holding, the onion in the chest, or one of
> the onions on the floor?" Which would be valuable with or without the
> ordinal system. Actually, it might make the ordinal system redundant.)
I think any system with a level of disambiguation this sophisticated
ought to allow the player to use the indefinate article; "an onion" to
mean "any onion", especially where the objects are equivalent.
Sir Pyke
really unnatural and hence confusing. Its not a due to the
implementation - but rather being bombarded with a list of individual
plain onions. What you call 'enchanced object names' sounds spot on the
mark.
Good stuff.
Sir Pyke.
samwyse
jealous! Since the first of the year, the only time I've had more than
thirty consecutive minutes of time to myself, I've been driving a car.
This makes thinking about things easy, but mmakes actually implementing
them hard. But enough about me...
On or about 4/20/2005 10:15 AM, Andrew Plotkin did proclaim:
> Here, samwyse <deja...@email.com> wrote:
>>The standard parser already knows about a few, hard-coded, properties.
>>The same code that handles the TWO in TAKE TWO CANDLES also understands
>>LIT, as in TAKE THE LIT CANDLES. The problem is that the word LIT is
>>hardcoded in the parser to mean objects with the 'light' property set,
>>there's no way to make HOT work similarly.
>
> You are entirely right. I've found (when writing actual games) that
> the library's hardcoded handling is worse than useless -- it's never
> what I want. I tried to set up massnoun.inf so that the properties are
> defined game-side. (I had partial success.)
The parser continues to be monolithic block of code that's in desperate
need of restructuring. To that end, I think that the notional part of
your code is extremely useful. It points out places where the parser
needs some callouts, so that those games can include a notional.h file
and get all the functionality, without wholesale replacement of
NounDomain and Parser__parse by the include file.
As an example that has nothing to do with your code, the parser
recognizes three "classes" of commands: a compass direction, a verb
followed by nouns and prepositions (which I will abbreviate as DO
SOMETHING), and modifiers to the preceeding (NPC, DO SOMETHING). It
would be great to be able to add additional classes, either by adding
new compass-like objects with implicit actions (just as compass
directions imply 'Go'), or by adding additional modifiers (TELL NPC TO
DO SOMETHING, HELP NPC TO DO SOMETHING.
>>I *still* haven't gotten around to coding anything with the Platypus
>>library, but for some reason I re-read the documentation every six
>>months or so. Platypus has generalized the above code, so an author can
>>add additional descriptors to the parser, thus providing a way to have
>>'hot' objects. (According to the docs, LIT isn't recognized, but EMPTY,
>>as in PUT THE MONEY IN THE EMPTY BAG, is).
>
> That's part of it. I had to work harder to get "six ounces of gold" to
> behave right. I'm assuming that measured quantities are going to be a
> common (though not universal) need in games that use continuous
> substances.
>>[...]
>>Another issue to consider is that there's no standard way to display
>>descriptors, i.e. no way for code like this:
>> "You pick up ",(the_adj)obj, ".";
>>to produce output like this:
>> You pick up the hot potato.
>
> This half of the problem is just as critical as the parsing half. The
> player can't type a meaningful command unless he knows what
> distinguishes the various instances in scope.
Getting back to massnoun.inf, there's obviously a need for enhancing
noun phrases in at least two ways. One is to generalize descriptors.
Ideally, an author could add a single object that represents
temperatures. It would have parse_descriptor and print_descriptor
methods, plus optional lists of useful comparitives (hot, hotter,
hottest) and their opposites (cold, colder, coldest). Just including
'temp.h' and 'color.h' would enhance the parser to better handle PICK UP
THE WARM RED POTATO.
> (One feature which I did not get around to coding: enhanced object
> names at disambiguation time. "Which onion do you mean, the onion on
> the table, the onion you're holding, the onion in the chest, or one of
> the onions on the floor?" Which would be valuable with or without the
> ordinal system. Actually, it might make the ordinal system redundant.)
And this would be the other enhancement, adding prepositional phrases to
noun phrases. Your example shows the need for hooks into the
disambiguation routines, since some obvious replies include THE TABLE,
THE ONE THAT I'M HOLDING, and IN THE CHEST.
Ross Presser
> Here, Ross Presser <rpre...@nospamgmail.com.invalid> wrote:
>> Fun to play with. But why can't I eat the vegetables? :)
>>
>>>take 10000 ball bearings
>> (extracing ten thousand metal items from the bucketful of ball bearings)
>> "You scoop 10000 ball bearings from the bucket."
>>
>> Boy, I'm strong...
>
> It's only 62 pounds. Peanuts.
>
> Pile a few of those together, however, and you'll run into some
> impressive overflow bugs. (16-bit variables, and I don't do any bounds
> checking.)
I guess you're right .. i was thinking of them as marble-sized, even though
you explicitly told me they weigh 0.1 oz each. They're sub-pea sized.
Things could get really fun if you made them magnetic. (And yellow. Then
they could be small yellow magnetic marbles, or SYMM-balls, to quote
Douglas Hofstadter.)
Damien Neil
<erky...@eblong.com> wrote:
> So what we want is a system that will (1) make it clear to the player
> what properties a unit has, and (2) allow the player to refer to any
> of those properties. And also (3) if two units are truly identical,
> distinguish them anyway as "first", "second", etc. so that the player
> can still refer to them.
I find the use of ordinals in massnoun to be somewhat confusing and
difficult to predict. I'm not certain if this is an implementation
detail or if the notion of using ordinals is a mistake.
For example:
You can see a chest (in which are a fourth plain onion, a red onion
and a fourth turnip), a cabinet (which is closed), three plain onions
and three turnips here.
As I read this, I get confused when I see "fourth plain onion"--where
are the other plain onions? Only at the end of the paragraph do I find
them on the floor.
Worse, I managed to get the following:
You can see a chest (in which are a second plain onion, a red onion
and a fourth turnip), a cabinet (which is closed), two plain onions
and three turnips here.
The first and third plain onions are unlabeled on the floor, and the
second is in the chest.
It might be less confusing if identical objects remained
indistinguishable.
- Damien
Andrew Plotkin
> In article <d44gn9$qeo$1...@reader1.panix.com>, Andrew Plotkin
> <erky...@eblong.com> wrote:
> > So what we want is a system that will (1) make it clear to the player
> > what properties a unit has, and (2) allow the player to refer to any
> > of those properties. And also (3) if two units are truly identical,
> > distinguish them anyway as "first", "second", etc. so that the player
> > can still refer to them.
>
> I find the use of ordinals in massnoun to be somewhat confusing and
> difficult to predict. I'm not certain if this is an implementation
> detail or if the notion of using ordinals is a mistake.
The implementation is somewhat arbitrary. This is because the problem
definition is.
> For example:
>
> You can see a chest (in which are a fourth plain onion, a red onion
> and a fourth turnip), a cabinet (which is closed), three plain onions
> and three turnips here.
>
> As I read this, I get confused when I see "fourth plain onion"--where
> are the other plain onions? Only at the end of the paragraph do I find
> them on the floor.
As I said in the game text, I tried to make numbers stick to objects
whenever possible. (If an object changes number every turn, as you
pick it up and drop it and open and close containers, etc, it's worse
than useless.)
This case would be slightly better if opening the chest had said
"Opening the chest reveals a fourth onion." (Currently it does not,
because recomputing numbers occurs between turns.) Then the overall
transcript would introduce it properly, although the room description
on its own would still be funky.
> Worse, I managed to get the following:
>
> You can see a chest (in which are a second plain onion, a red onion
> and a fourth turnip), a cabinet (which is closed), two plain onions
> and three turnips here.
>
> The first and third plain onions are unlabeled on the floor, and the
> second is in the chest.
Yes, I seem to have written code where a single object by itself gets
labelled, but two or more together get their labels obscured. This
would be easy to fix, either way. I guess I'll try this:
...two plain onions (the first and the third), and three turnips (the
first, the second, and the third).
Of course then there's the sorting of numbers, which I haven't even
tried to do.
> It might be less confusing if identical objects remained
> indistinguishable.
I am leaning towards this position myself. But the idea still might be
valuable in some games.
Mark J. Tilford
I believe the Inform parser already does this.
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>Can you express
>commands that do what you'd want to do in a real game with fluids?
Are you asking me in my capacity as occasional author of Stiffy Makane
epics?
Adam
David Fisher
> My theory is this: there is usually a sensible way to divide up the
> substance, such that each unit is an IF-style "thing". That is, the
> player will want to refer to one unit per command. (I should say, the
> player will want to refer to one unit per noun phrase. "Put X in Y" is
> two noun phrases.) There may be water in the bottle, a puddle of water
> on the floor, and a lake nearby. Each of those should be one IF
> object.
>
> That much is not controversial. The reason this falls apart in
> implementation is this: the player can't figure out how to refer to a
> particular IF object. They're all called "water".
>
> This problem should be solvable. The whole point of having several
> units of a substance in a game -- presumably! -- is that they differ
> in some way. Location, form, quantity, temperature, color. The various
> bits of water have properties, and these properties distinguish them.
>
> So what we want is a system that will (1) make it clear to the player
> what properties a unit has, and (2) allow the player to refer to any
> of those properties. And also (3) if two units are truly identical,
> distinguish them anyway as "first", "second", etc. so that the player
> can still refer to them.
I like the general idea of using ordinals, but it seems to get messy in
situations with more than one indistinguishable object. When all objects are
singular - as in "a potato on the table and a second potato on the floor" -
it works very well.
There is a tricky problem using prepositions to distinguish objects
(probably obvious but I'll say it anyway) - whether the proposition belongs
with the verb or the noun in sentences of the form Verb + Noun +
Preposition. For example:
#> Hit the dwarf with the axe
- which could mean:
* hit (the dwarf with the axe), ie. hit the dwarf who has the axe
* hit (the dwarf) (with the axe), ie. use the axe on the dwarf
Something extra-tricky about this kind of thing is that the ambiguity is
with the way to parse the whole sentence, not just which object is being
referred to (as in, "the green axe or the blue axe"). What should the parser
ask the player ? Maybe something like:
"Do you mean hit <with the axe> the dwarf, or hit <the dwarf with the axe>
?"
David Fisher
cub...@aol.com
NOUN1 WITH NOUN2 automatically regards NOUN2 as the thingie that the
player is going to hit NOUN1 with. If NOUN1 happens to be "THE DWARF
WITH THE AXE", this could result in a player typing the somewhat
bizarre command HIT THE DWARF WITH THE AXE WITH THE AXE, but life is
tough all over. Hopefully, the parser will be able to cope with HIT THE
AXE-WIELDING DWARF WITH THE AXE, and similar commands that use
rephrased versions of "THE DWARF WITH THE AXE".
Andrew Plotkin
> David Fisher wrote:
> >
> > There is a tricky problem using prepositions to distinguish objects
> > (probably obvious but I'll say it anyway) - whether the proposition
> belongs
> > with the verb or the noun in sentences of the form Verb + Noun +
> > Preposition. For example:
> >
> > #> Hit the dwarf with the axe
> >
> > - which could mean:
> >
> > * hit (the dwarf with the axe), ie. hit the dwarf who has the axe
> > * hit (the dwarf) (with the axe), ie. use the axe on the dwarf
>
> NOUN1 WITH NOUN2 automatically regards NOUN2 as the thingie that the
> player is going to hit NOUN1 with.
That was my thought. (Always disambiguate in favor of the second
option, as David lists them.) And, really, the game designer should
put in enough cues that the player doesn't *need* to run into this
problem. If one dwarf is grumpy and one is sleepy, the player will use
those as descriptors and not try to worry about who has what weapon.
Pleasantly, "put X on Y" -- the most common source of confusion --
avoids this problem automatically, because if the X is on the Y
already then you're not trying to put it there!
Al Turniansky
da...@hsa.com.au wrote on 4/24/05 9:26 PM:
Of course, that sentence would (ideally) only be ambiguous if both you *and*
one of the dwarves had axes.
Maybe there is a need for parsing "who has" or "that has", so that
"Hit the dwarf that has an axe"
or
"Hit the dwarf who has an axe"
would be interpretable.
(Of course, there's always the alternative of "the axe-wielding dwarf", but
that seems to me a bit inflexible, in that it's a silly thing to have to
call him once you have relieved him of his axe.)
David Fisher
news:BE92BB2D.B3B6%alturn...@prodigy.net...
> in article KCYae.8971$Le2....@nasal.pacific.net.au, David Fisher at
> da...@hsa.com.au wrote on 4/24/05 9:26 PM:
>>
>>
>> - which could mean:
>>
>> * hit (the dwarf with the axe), ie. hit the dwarf who has the axe
>> * hit (the dwarf) (with the axe), ie. use the axe on the dwarf
>
> *and*
> one of the dwarves had axes.
>
> Maybe there is a need for parsing "who has" or "that has", so that
>
> "Hit the dwarf that has an axe"
>
> or
>
> "Hit the dwarf who has an axe"
>
> would be interpretable.
>
> (Of course, there's always the alternative of "the axe-wielding dwarf",
> but
> that seems to me a bit inflexible, in that it's a silly thing to have to
> call him once you have relieved him of his axe.)
"The no longer axe-wielding dwarf " ? (cf. "The musician formerly known as
Prince") :-)
Actually, it would be pretty good if the parser could understand "the dwarf
without an axe". I'd be impressed, anyway.
Using "that has" / "who has" is pretty natural for the player (and so they
wouldn't need to learn a special syntax - just use normal english), but it
could potentially require number agreement & plurals ("who has an axe" vs
"who have axes"). I feel slightly uncomfortable with the parser silently
choosing one meaning when the sentence is genuinely ambiguous (cf. Zarf's
suggestion of always interpreting the original sentence as "Use the axe on
the dwarf"). I can't think of any other options right now, though ...
Would it be an "evil" thing for the player to have no way of saying
something without having to then disambiguate ? (eg. "Do you mean hit <with
the axe> the dwarf, or hit <the dwarf with the axe> ?" as in the previous
post).
David Fisher
David Fisher
> I feel slightly uncomfortable with the parser silently choosing one
> meaning when the sentence is genuinely ambiguous
> (cf. Zarf's suggestion of always interpreting the original sentence
> as "Use the axe on the dwarf").
Sorry, that was "cubist's" suggestion as well as Zarf's ... not meaning to
ignore your input, cubist !
David Fisher
samwyse
> Using "that has" / "who has" is pretty natural for the player (and so they
> wouldn't need to learn a special syntax - just use normal english), but it
> could potentially require number agreement & plurals ("who has an axe" vs
> "who have axes"). I feel slightly uncomfortable with the parser silently
> choosing one meaning when the sentence is genuinely ambiguous (cf. Zarf's
> suggestion of always interpreting the original sentence as "Use the axe on
> the dwarf"). I can't think of any other options right now, though ...
The current parser allows disagreements of this sort in many cases,
mostly because the player will tend to use the correct syntax and never
notice that the parser allows incorrect syntax.
> Would it be an "evil" thing for the player to have no way of saying
> something without having to then disambiguate ? (eg. "Do you mean hit <with
> the axe> the dwarf, or hit <the dwarf with the axe> ?" as in the previous
> post).
There's already a mechanism for choosing an object when a noun phrase is
ambiguous (ChooseNoun). I can't see a reason why the parser couldn't
try to parse the entire command in several ways, score each attempt, and
go with the best.
David Fisher
news:FJgbe.341$gd5...@newssvr12.news.prodigy.com...
>
> On or about 4/25/2005 7:20 PM, David Fisher did proclaim:
>> something without having to then disambiguate ? (eg. "Do you mean hit
>> <with the axe> the dwarf, or hit <the dwarf with the axe> ?" as in the
>> previous post).
>
> There's already a mechanism for choosing an object when a noun phrase is
> ambiguous (ChooseNoun). I can't see a reason why the parser couldn't try
> to parse the entire command in several ways, score each attempt, and go
> with the best.
I guess the player would get used to the parser choosing a particular
interpretation (probably unconsciously) ...
Though I still think there are cases where a command is genuinely ambiguous
(ie. the "score" for each parse is the same), and it goes against the grain
for me if the parser just chooses one (even if it is done consistently).
Just my own opinion :-)
David Fisher
Tikitu
disambiguating verbs against nouns) why not show that explicitly?
#> hit the dwarf with the axe
(hitting with the axe)
(the sleepy dwarf)
...
#> hit the dwarf with the axe with the axe
(hitting with the axe)
...
#> hit the dwarf with the axe with the club
and so on. With such a system I imagine "the dwarf without an axe"
wouldn't actually be so hard, the complexity is I guess in the
treatment of genitives [DM4 sec 34] in the first place.
Of course the full PP attachment problem is trickier than this. "Hit
the troll with the dwarf with the axe in his pocket" has a whole bunch
of parses (the most natural one doesn't work with the object model, and
at least one other is extremely politically incorrect).
(Full disclosure, since this is my first post here: my monumental first
WIP is currectly stalled, but so far hasn't involved any grammar
hacking. I do have some sort of linguistics background though.)
Tikitu
Rikard Peterson
@o13g2000cwo.googlegroups.com:
> erk -- "currectly" -> "currently", not "correctly" ;-)
Well, the first post on a group almost has to be either stupid or
contain spelling errors, so you should be glad you only have spelling.
:)
A suggestions for future posts: Please quote the relevant parts of the
post you're replying to. I see you're using Google to post, which
doesn't make that as easy as real newsreaders, but the effort will be
appriciated.
And welcome!
Rikard
Tikitu
the
> post you're replying to.
will do. should know better.
> And welcome!
thanks :-)
Damien Neil
Andrew Plotkin <erky...@eblong.com> wrote:
> Here, Damien Neil <neild-...@misago.org> wrote:
> > I find the use of ordinals in massnoun to be somewhat confusing and
> > difficult to predict. I'm not certain if this is an implementation
> > detail or if the notion of using ordinals is a mistake.
>
> The implementation is somewhat arbitrary. This is because the problem
> definition is.
I've been thinking about this some more. This led to a game idea, which
led to a further realization of how tricky this problem is.
Ordinals do have a purpose, I now realize: If you're dealing with a
number of very similar, but not completely identical objects, they may
be the easiest way to reference things.
Imagine, for example:
You can see a bust of Niels Bohr here.
A lump of clay is stuck to Niels Bohr's nose.
A second lump of clay is stuck to Niels Bohr's nose. A penny is
embedded in it.
A third lump of clay is stuck to Niels Bohr's left eye. A penny is
embedded in it.
Commands such as "GET THE LUMP OF CLAY WITH A PENNY IN IT FROM NIELS
BOHR'S NOSE" would be much nicer as "GET THE SECOND LUMP OF CLAY".
This is a different usage than massnoun, however--where massnoun uses
ordinals only to distinguish otherwise identical objects, this would be
a shortcut method of identifying mostly similar ones.
> As I said in the game text, I tried to make numbers stick to objects
> whenever possible. (If an object changes number every turn, as you
> pick it up and drop it and open and close containers, etc, it's worse
> than useless.)
I agree that numbers need to stick. I'm uncertain exactly how they
should stick. It feels somewhat wrong to me if you can drop "the third
ball bearing" down a hole, and have it turn up on the floor half a game
later bearing the same number. (How do I know that this anonymous ball
bearing is the one I dropped down the hole?)
That might be best solved by the game author manually flagging an object
as "lost", which would clear its ordinal.
Would it be sensible if the numbers were recalculated every time the
player changed rooms?
- Damien
samwyse
> In article <d497up$mh4$1...@reader1.panix.com>,
> Andrew Plotkin <erky...@eblong.com> wrote:
>
>>Here, Damien Neil <neild-...@misago.org> wrote:
>>
>>>I find the use of ordinals in massnoun to be somewhat confusing and
>>>difficult to predict. I'm not certain if this is an implementation
>>>detail or if the notion of using ordinals is a mistake.
>>
>>The implementation is somewhat arbitrary. This is because the problem
>>definition is.
>
>
> I've been thinking about this some more. This led to a game idea, which
> led to a further realization of how tricky this problem is.
>
> Ordinals do have a purpose, I now realize: If you're dealing with a
> number of very similar, but not completely identical objects, they may
> be the easiest way to reference things.
> I agree that numbers need to stick. I'm uncertain exactly how they
> should stick. It feels somewhat wrong to me if you can drop "the third
> ball bearing" down a hole, and have it turn up on the floor half a game
> later bearing the same number. (How do I know that this anonymous ball
> bearing is the one I dropped down the hole?)
>
> That might be best solved by the game author manually flagging an object
> as "lost", which would clear its ordinal.
>
> Would it be sensible if the numbers were recalculated every time the
> player changed rooms?
I think that the numbers should be recalculated with every LOOK. This
allows them to be assigned in a reasonable order, and gives a solution
of sorts to the 3rd ball bearing problem: Instead of clearing the
ordinal directly, do another LOOK. That would both re-number the balls
(closing any gaps), and communicate the new ordering to the player. The
whole thing could be done with code similar to that used to number
footnotes. Other ways of assigning ordinals IMHO risk resulting in
something like this:
You can see a bust of Niels Bohr here.
A third lump of clay is stuck to Niels Bohr's nose.
A lump of clay is stuck to Niels Bohr's nose. A penny is
embedded in it.
A second lump of clay is stuck to Niels Bohr's left eye. A penny is
embedded in it.