Using Smalltalk for IF (also space habitats and sound adventures)
Paul Fernhout
Hi!
I've been lurking here on and off for a year and I thought I'd post
something on what I want to do with IF to get people's opinions on it.
I know there are some very good tools out there to use for IF (Inform
looks especially cool). However, since I know Smalltalk fairly well, I
am interested in using Smalltalk for writing Interactive Fiction.
The advantages I see to using Smalltalk for IF are:
* Smalltalk supports modifying a program while it runs
* Smalltalk is a very flexible language
* Smalltalk has very good debugging tools
* Smalltalk already runs on several platforms
* Smalltalk can easily take on large projects
* Smalltalk is a complete development system, so if you want to build a
fuzzy logic system into your adventure (or genetic algorithm or
stochastic weather simulator), you can do it.
* Smalltalk could support multilanguage development (like allowing some
code to be in Inform or an Inform-like syntax if you added an Inform
interpreter in Smalltalk to the system).
* "Smalltalk" is a nice name for an IF authoring language
* It is very object oriented - lending itself to IF that writes itself
from expressing the goals of agents (given the right supporting classes
of course). (Gee, maybe Erasmatazz would license their technology?)
There is a freely redistributable Smalltalk called "Squeak" released
(with source) that runs under Win32, Mac, UNIX, Acorn, WinCE, and some
other platforms. Apple released it about a year ago under a very
permissive license. I'm looking into porting it to the Newton. People
have even added a web server capability to it (useful for MUDs).
You can download if for free from:
http://www.create.ucsb.edu/squeak/
I would like to use Squeak to build text-based interactive fiction.
Specifically I want to create a world set in 3000 AD based on realistic
science (so, somewhat educational) amidst billions of O'Neill
cylindircal and Savage bubble style space habitats. It would sort of be
like Starcross, only a habitat is your home and you might visit other
habitats with different cultures. ("Oooh, silly, why would you want to
visit a gravity well like *Earth*?")
Ideally, I would like to build in some capacity to define agents and let
the story unfold (like the work going on a CMU (OZ) and elsewhere).
Does anybody know of an existing set of IF classes in Smalltalk (besides
Castle Microsloth), preferably redistributable?
Would there be any legal issues with taking the Inform libraries and
rewriting them in Smalltalk and redistributing them? Would I need to
license these (i.e. probably from Graham Nelson)?
Would anybody (besides me) use such a system, given the existence of
several nice engines people know how to use, and other great ideas (like
Erasmatazz) on the way?
Is it silly to reinvent the wheel, or are people chafing at Inform and
TADS limitations?
How many people could I expect to pay for such an authoring tool (with
manual & support - say at $100 or $200). [10, 100, 1000, 10000?]
{I guess the Erasmatazz people think there is a market for IF
development tools.}
Would people pay $45 to get this system as a book (with CD)?
Should I just plan to give it away (and perhaps in that case get others
involved in its development)?
If so, anyone interested in helping on it if it were to be given away?
If I did put this work out for free, what sort of license would people
want to see on it:
* like Python, do whatever you want - http://www.python.org
* like Squeak, return changes and bug fixes if made to the base. This
license is also being used by the Educational Object Economy started by
Apple - see http://trp.research.apple.com/edeconomy/info.html
* like GPL/GNU - return everything you do with it (maybe including
adventures?) - http://www.fsf.org
* like some standard shrinkwrapped software - own your game, but you
can't redistribute improvements you make to the engine
Should this license extend to the games produced with the system
(assuming they could build upon characters and objects I developed as
part of a background)? For example, a GPL license to the system might
be considered to extend to any code (i.e. games) you wrote with the
system.
I created an eight room / two object demo adventure program (in Delphi,
using Microsoft Whisper Speech Recognizer and Monologue TTS) that you
could say one word commands and the system would speak your location
information and play some sound effects (take and drop just worked on
the first thing on the ground or in inventory). You didn't have to look
at a monitor or use a keyboard to play the ten minute game. Would
support for something like this be compelling enough to make people
learn a new development system in Smalltalk (probably only running under
Win32)? [I guess this could be added to Inform too of course - like
using $99 IBM ViaVoice and the free developer kit].
Does the scenario of "realistic science in a space habitat setting" perk
anyone's interest? Would people want to adventure in such a world?
Would anyone be interested in writing or extending such adventures if I
created the scientific and technical background? In this setting, there
would be no FTL warp drive, no transporters, no phasers, no replicators,
and no artifical gravity. However, there would be AI, genetic
engineering, a trillion humans living in the solar system, O'Neill
habitats, advanced robotics, self-replicating machinery, flexible
on-demand manufacturing, cultural drift, cyborgs, and implanted
cellphones & web interfaces. Is it likely people would like to build on
top of such a setting, or is the situation more that people just want to
work on their own stuff in their own settings?
Any comments on all this would be appreciated.
-Paul Fernhout
Kurtz-Fernhout Software
===========================================================
Developers of custom software and educational simulations
Download version 1.0 of our Garden Simulator for Windows from:
http://www.gardenwithinsight.com
Sean Selvidge
Paul Fernhout wrote:
[MUCH SNIPPAGE]
> How many people could I expect to pay for such an authoring tool (with
> manual & support - say at $100 or $200). [10, 100, 1000, 10000?]
> {I guess the Erasmatazz people think there is a market for IF
> development tools.}
> Would people pay $45 to get this system as a book (with CD)?
Unless you are going to write it from scratch I don't think you should
try to get money for it at all. You said in an earlier portion of your
post that you want to use stuff from existing I-F systems. I think that
would cause copywrite problems if you don't actually write it all
yourself.
Also I don't know why anyone would pay for a NEW way to build I-F when
there are several well supported free options to go with. If people
are too lazy to type out all the code then they are probably too lazy
to complete a work of IF.
Uh oh!
>WEAR GEAR
(first taking the gear)
You wear your flame retardant riot gear.
-S
jken...@himail.hcc.com
In <34274C...@netins.net>, Paul Fernhout <kfs...@netins.net> writes:
>I know there are some very good tools out there to use for IF (Inform
>looks especially cool). However, since I know Smalltalk fairly well, I
>am interested in using Smalltalk for writing Interactive Fiction.
>The advantages I see to using Smalltalk for IF are:
>[list]
There are some problems I can see with Smalltalk:
Only single inheritance. IF is a domain in which multiple inheritance
is quite desireable.
Save/Restore/Undo. In a lab, you can naturally just save your
whole environment or workspace or whatever it's called, but
that's much too expensive for IF (especially for Undo). Coding
a Save/Restore/Undo game in Smalltalk wouldn't be too difficult
-- a texbook exercise in fact -- but it might be painfully slow
-- perhaps intolerable for Undo.
Speed. A lot of IF function ends up being implemented by way
of "broadcast this message to every game object".
>Would there be any legal issues with taking the Inform libraries and
>rewriting them in Smalltalk and redistributing them? Would I need to
>license these (i.e. probably from Graham Nelson)?
I cannot speak for Graham, but I know enough about Inform and
about Smalltalk to know that there wouldn't be much left of his
original code by the time you got through with it. You might
want to put a "Thanks to Graham Nelson" note in your README.
>Is it silly to reinvent the wheel, or are people chafing at Inform and
>TADS limitations?
I can think of only one serious z-machine restriction that could not be
easily lifted by defining a new version and changing a line or two in
present interpreters. (i.e., by once again increasing the packed-address
shift.) Work is already being done to add graphics, music, and sound
effects. And if the one remaining restriction begins to bite (it hasn't
yet), it would still be possible, albeit with rather more work, to devise
a "new z machine" that would raise all limits to, for all practical IF
purposes, infinity. (By doubling the size of zchars and zwords.)
Inform, of course, is not the z machine. I could wish Inform a little
different (in particular, to be more like C wherever it is now only
almost-but-not-quite like C), but it's fairly complete.
The Inform library has faults here and there, but by now the parser
is almost as sophisticated as Infocom's V1-V5 parsers and the world
modeling is a good base to start from. (Many of the common problems
in world modeling now have well-known solutions freely available.)
Inform also has the benefit of internationalization support. Are you
prepared to include that?
>Does the scenario of "realistic science in a space habitat setting" perk
>anyone's interest? Would people want to adventure in such a world?
Why on Earth not?
>Would anyone be interested in writing or extending such adventures if I
>created the scientific and technical background? In this setting, there
>would be no FTL warp drive, no transporters, no phasers, no replicators,
>and no artifical gravity.
Babylon 5 has little of those (hyperspace permits FTL travel, and some
alien races, but not Humans, have artificial gravity) and it seems to do
well enough. It's also set in an O'Neill station.
>Is it likely people would like to build on
>top of such a setting, or is the situation more that people just want to
>work on their own stuff in their own settings?
I don't know. Many people have written stories in the Zork universe
(even more if you count the ones who filed off the serial numbers
first), but few have ventured into others, except to make extended
versions of "Colossal Cave". However, I'm not aware of anyone
having created a full IF world in software for others to use.
"Modules" certainly seem to work for tabletop paper-and-dice games.
Paul Fernhout
Sean -
Thanks for the reply. No need for the flame retardant riot gear; I
posted this to get people's opinions.
Sean Selvidge wrote:
> Unless you are going to write it from scratch I don't think you should
> try to get money for it at all. You said in an earlier portion of your
> post that you want to use stuff from existing I-F systems. I think that
> would cause copywrite problems if you don't actually write it all
> yourself.
Legally, the copyright problems would come about if I translated the
Inform library to Smalltalk just because Graham Nelson owns the
copyright (whether I charged for it or not), and unless he has given
people permission to redistribute the library code (in translation), I
probably would have to reinvent it from scratch.
Morally, you are very correct. It would be an extremely annoying thing
to work hard on something, give it away for free (having never been paid
for developing it), and then see someone trying to make money off of it
(and not giving you a cut). I would not do that, which is why I posted
the original query. Maybe I should email Graham directly -- though the
"best system faq" says he gets too much email already.
> Also I don't know why anyone would pay for a NEW way to build I-F when
> there are several well supported free options to go with. If people
> are too lazy to type out all the code then they are probably too lazy
> to complete a work of IF.
Good point.
But there is always the issue of new features... I know this topic
(creating a new system) is also mentioned in the "which system is better
faq" (as in, "don't do it..."). Still, I just think the potential for
doing IF in a very comprehensive programming system has some advantages
(especially one like Squeak Smalltalk where you could build on tools to
help avoid needing to type lots of code - like a graphical map editor
for example).
However, whether people would pay for this is another story. If the
market is a few hundred people who are already happy with what they
have, it makes much more sense to give the thing away and get other
people's support in developing it.
There is no question that the system would get built much faster and
better if it leveraged off of Inform's libraries though.
Paul Fernhout
Thanks for the reply. Some comments are below.
jken...@himail.hcc.com wrote:
> There are some problems I can see with Smalltalk:
>
> Only single inheritance. IF is a domain in which multiple inheritance
> is quite desireable.
True, but multiple inheritence can often be supported through
composition of properties. For example, you have a club property, and
light provider property, and container property, and you make a police
flashlight by combining the three properties in one "object". The
objects themselves don't have to have multiple inheritence.
As it is, I might need to make some changes to Squeak to make it more
suitable for IF - but luckily, it comes with source code.
>
> Save/Restore/Undo. In a lab, you can naturally just save your
> whole environment or workspace or whatever it's called, but
> that's much too expensive for IF (especially for Undo). Coding
> a Save/Restore/Undo game in Smalltalk wouldn't be too difficult
> -- a texbook exercise in fact -- but it might be painfully slow
> -- perhaps intolerable for Undo.
True, but you can reduce the size of the game file by storing only the
relevant part through binary storage (using a binary storage system -
although Squeak has none), or by having each object know how to write
itself out as text and read itself back in (admittedly there are
reference issues to deal with in this case).
I usually handle Undo in projects by making command objects that store
enough information to restore the system to a state prior to the command
being started.
> Speed. A lot of IF function ends up being implemented by way
> of "broadcast this message to every game object".
Is a Z-machine is going to be very much faster than the Squeak VM (which
is 1/60th the speed of C)? A new VM is in the works for Squeak that may
approach 1/10th the speed of C.
Smalltalk has good support for dependency - making one object dependent
on another and listening for messages from it. This can be used to
reduce the number of messages that need to be sent (since only an
objects dependents need to get the message). Still, a dependency
mechanism may not be enough to handle every IF contingency easily and
may require more programming to manage dependencies.
> >Would there be any legal issues with taking the Inform libraries and
> >rewriting them in Smalltalk and redistributing them? Would I need to
> >license these (i.e. probably from Graham Nelson)?
>
> I cannot speak for Graham, but I know enough about Inform and
> about Smalltalk to know that there wouldn't be much left of his
> original code by the time you got through with it. You might
> want to put a "Thanks to Graham Nelson" note in your README.
You are probably right - the result would be hardly recognizeable.
Still, the Inform library is his code, and so I probably need to get his
permission to translate it if I expect to redistribute it (even for
free) when I am done.
[snip - comment on z-machine]
Thanks for the background on z-machine issues and where the z-machine is
going.
It is hard to explain all the potential of doing IF in a complete
Smalltalk development environment (like making graphical tools to
automate design tasks like laying out a set of connected rooms, or
building in an automated testing tool, or having version control to roll
back changes or allow multiple authors to merge their work).
> Inform also has the benefit of internationalization support. Are you
> prepared to include that?
>
Probably not at the start...
[snip - cute comment]
> Babylon 5 has little of those (hyperspace permits FTL travel, and some
> alien races, but not Humans, have artificial gravity) and it seems to do
> well enough. It's also set in an O'Neill station.
>
True, but the whole B5 scenario is still centered around fighting over
scarce "habitable planets". There aren't a trillion B5 habitats. I want
to get people to stop writing sci-fi about finding & fighting over
scarce habitable planets, and start writing sci-fi about a future where
we can support trillions in style in this solar system in human made
space structures.
See http://www.gardenwithinsight.com/solarius/ for something I wrote as
the start of such an interactive fiction adventure in a space habitat.
See http://members.aol.com/oscarcombs/settle.htm for more info on space
habitats in general.
> >Is it likely people would like to build on
> >top of such a setting, or is the situation more that people just want to
> >work on their own stuff in their own settings?
>
> I don't know. Many people have written stories in the Zork universe
> (even more if you count the ones who filed off the serial numbers
> first), but few have ventured into others, except to make extended
> versions of "Colossal Cave". However, I'm not aware of anyone
> having created a full IF world in software for others to use.
> "Modules" certainly seem to work for tabletop paper-and-dice games.
Thanks for the perspective.
Magnus Olsson
In article <342845...@netins.net>,
Paul Fernhout <kfs...@netins.net> wrote:
>Sean -
>
>Thanks for the reply. No need for the flame retardant riot gear; I
>posted this to get people's opinions.
>
>Sean Selvidge wrote:
>> Unless you are going to write it from scratch I don't think you should
>> try to get money for it at all. You said in an earlier portion of your
>> post that you want to use stuff from existing I-F systems. I think that
>> would cause copywrite problems if you don't actually write it all
>> yourself.
>
>Legally, the copyright problems would come about if I translated the
>Inform library to Smalltalk just because Graham Nelson owns the
>copyright (whether I charged for it or not), and unless he has given
>people permission to redistribute the library code (in translation), I
>probably would have to reinvent it from scratch.
Legally, code falls under copyright; ideas don't. You can't copyright an
algorithm. You can patent it, however.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.
jken...@himail.hcc.com
>True, but the whole B5 scenario is still centered around fighting over
>scarce "habitable planets".
Obviously off-topic, so I'll only say I am absolutely bog-woggled at this
remark.
Graham Nelson
In article <608kkv$8...@decgate.bridgewater.ne.hcc.com>,
<URL:mailto:jken...@himail.hcc.com> wrote:
> The Inform library has faults here and there, but by now the parser
Begging your pardon, m'lud, but it's vastly more sophisticated
than the Infocom parser was: Infocom hand-wrote a different version
of the parser for every single game, in a really hacky way. There's
no philosophy of "here's a library to use" about it: the Implementors
more or less tore the parser code out of Zork I and stuck on
whatever features they felt like. In the case of, e.g., "Spellbreaker"
this took a lot of messing about. Of course partly this indulged
the passion felt by some of the Implementors for writing better
and better parsers from scratch. I forget which one of them claimed
to have written something like 50?
Name one thing the Infocom parser (in so far as there is one
single Infocom parser) could handle that the standard, unenhanced,
unprogrammed Inform parser can't! And I'll probably be glad to add
it. I don't believe any of the Infocom games contain proper
parsing of plurals ("get three of the toads"), groups of
indistinguishable objects, etc.: and most of the nicer features, like
"undo", are only present in the later games. Here's the final
release of Zork II:
Inside the Barrow
You are inside an ancient barrow hidden deep within a dark forest. The
barrow opens into a narrow tunnel at its southern end. You can see
a faint glow at the far end.
A strangely familiar brass lantern is lying on the ground.
A sword of Elvish workmanship is on the ground.
>x it
I don't know the word "x".
>examine it
There's nothing special about the .
>pronouns
I don't know the word "pronouns".
>oops sword
I don't know the word "oops".
>dragon sword
There was no verb in that sentence!
[Note that it doesn't respond "I don't know the word "dragon".",
so it has inadvertently revealed the existence of a dragon to us.
Likewise, trying "get gold" and then "get silver" demonstrate
that the game contains the former and not the latter.]
Sophisticated stuff! And compare that to
You can see a plastic fork, knife and spoon, three hats (a fez, a
Panama and a sombrero), the letters X, Y, Z, P, Q and R from a
Scrabble set, a defrosting Black Forest gateau, Punch magazine,
a recent issue of the Spectator, a die and eight stars (four silver,
one bronze and three gold) here.
>get three silver stars
silver star: Taken.
silver star: Taken.
silver star: Taken.
>get a hat
(the fez)
Taken.
We shouldn't allow the golden memory of Infocom to blind our critical
faculties altogether. Their work was brilliant and pioneering, but
(on the implementation side at least) it is no longer the state of
the art, and their early- and middle-period parsers were looking
quite rickety as early as 1988 or so.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Edan Harel
Graham Nelson <gra...@gnelson.demon.co.uk> writes:
> Name one thing the Infocom parser (in so far as there is one
>single Infocom parser) could handle that the standard, unenhanced,
>unprogrammed Inform parser can't! And I'll probably be glad to add
>it.
Although I know it's probably probable to do, how about support for
the examples given in the LToI manuals (Don't know if they were in any
games):
>Boy, go home and then go to the police and tell them about the murder.
(Or something like that. Basically, giving a character more than
one command at a time).
Or how about handling three or four nouns:
>John, put the battery in the slot in the flashlight.
[Not a flame, I just want to know if they're things that can be (easily)
done in inform, and if not, I'd like to see them added, if possible]
--
"I have yet to see any problem, however complicated, which, when you looked
at it the right way, did not become still more complicated." -Poul Anderson
"For every problem, there is one solution which is simple, neat and wrong."
-H. L. Mencken
Mark J Musante
jken...@himail.hcc.com wrote:
> In <34284C...@netins.net>, Paul Fernhout <kfs...@netins.net> writes:
>
> >scarce "habitable planets".
>
> remark.
Are you sure you don't mean "nonplussed" :-)
-=- Mark -=-
Matthew T. Russotto
In article <ant2410470b0M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
} Name one thing the Infocom parser (in so far as there is one
}single Infocom parser) could handle that the standard, unenhanced,
}unprogrammed Inform parser can't! And I'll probably be glad to add
}it.
Well, there's the helpful hints offered by the Zork Zero parser. Also
there's the fact that the Infocom parser distinguished between nouns
and adjectives, though whether that is at all useful is another
question. It does mean you can get a few odd things to work in Inform
games, but I don't know of any real problem. But I just bring those
two up to cause trouble -- I agree that your parser is much more
sophisticated than the Infocom parsers, particularly the early ones.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
BrockBadge
Graham Nelson's Zork II <gra...@gnelson.demon.co.uk> writes:
> >examine it
> There's nothing special about the .
Mine says:
>examine it
There's nothing special about the gA wmfwtshs.
Hmm.... ( i had never seen this before... )
>>BKNambo "lost and confused, trying to find a gA wmfwtshs"
H newsm...@earthling.net -Spam me, I dare ya ____ __
=@==== http://members.aol.com/brockbadge/index.html /_ \ / /
H H H "World Domination Through Trivia" -S3Kitties / /\ \/ /
H H H Marcher -- Just my imagination -- Nightwatch /_/ \__/
Stuart George
hey graham-kun,
Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
: Name one thing the Infocom parser (in so far as there is one
: single Infocom parser) could handle that the standard, unenhanced,
: unprogrammed Inform parser can't! And I'll probably be glad to add
: it. I don't believe any of the Infocom games contain proper
: parsing of plurals ("get three of the toads"), groups of
: indistinguishable objects, etc.: and most of the nicer features, like
: "undo", are only present in the later games. Here's the final
: release of Zork II:
mm the last time i played an inform made game (a fair while, i admit)
follow was seriously lacking.
in magnetic scrolls, if you followed someone and they went from
room a to b to c, when you followed to room b and they moved
again, you only had to hit enter and you automatically
followed. now the last inform made game (err might have
actually been infocom, so....) you had to retype the command
every room you followed the actor into.
nitpicky nad probably easily added, but i remeber
being irritated at having to type "g" againt instead of
just enter (eeep, talk about being nitpicky in having
to type an extra letter -_-)
ja matte ne
--
-df
Dark Fiber [Entropic Coders]
Member of Juukinzoku Game Developement
http://acm.vt.edu/~dpark/juukinzoku
Head honcho of the Ed Wood school of FanFiccing
Magnus Olsson
In article <60cbuf$l...@wanda.vf.pond.com>,
Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
>In article <ant2410470b0M+4%@gnelson.demon.co.uk>,
>
>} Name one thing the Infocom parser (in so far as there is one
>}single Infocom parser) could handle that the standard, unenhanced,
>}unprogrammed Inform parser can't! And I'll probably be glad to add
>}it.
>
>there's the fact that the Infocom parser distinguished between nouns
>and adjectives, though whether that is at all useful is another
>question.
Adjectives is easy to add to the Inform parser - in fact, a simple
implementation is in the Manual (and a more advanced one can be found
in the IF-archive). OK, so the question was about the "standard,
unenhanced" parser. Maybe Graham should make adjectives a standard
feature?
The distinction between nouns and adjectives can be very helpful,
for example to avoid things like
> examine cat
Which cat do you mean, the black cat, the cat food, or the tin of
cat food?
By making cat an "adjective" for the cat food and the tin, but
a "noun" for the black cat, you can avoid the ambiguity.
Matthew T. Russotto
In article <19970925114...@ladder02.news.aol.com>,
BrockBadge <brock...@aol.com> wrote:
}Graham Nelson's Zork II <gra...@gnelson.demon.co.uk> writes:
}
}> >examine it
}> There's nothing special about the .
}
}Mine says:
}
}>examine it
}
}There's nothing special about the gA wmfwtshs.
}
}Hmm.... ( i had never seen this before... )
It's trying to access object 0's name, IIRC. Results are undefined.
And this is something of a low blow because it's just a bug, not a serious
parser shortcoming. Zork I sidestepped the problem by having "it" be
the mailbox initially.
Graham Nelson
In article <60djfr$f8v$1...@bartlet.df.lth.se>, Magnus Olsson
<URL:mailto:m...@bartlet.df.lth.se> wrote:
>
> Adjectives is easy to add to the Inform parser - in fact, a simple
> implementation is in the Manual (and a more advanced one can be found
> in the IF-archive). OK, so the question was about the "standard,
> unenhanced" parser. Maybe Graham should make adjectives a standard
> feature?
>
> The distinction between nouns and adjectives can be very helpful,
> for example to avoid things like
>
> > examine cat
>
> Which cat do you mean, the black cat, the cat food, or the tin of
> cat food?
>
> By making cat an "adjective" for the cat food and the tin, but
> a "noun" for the black cat, you can avoid the ambiguity.
Umm. Yes, I never know whether the decision to opt for a purely
noun-based parser was a brilliantly elegant coup of simplification
or a dunderheaded lack of imagination. Somewhere in between,
I expect. I can see arguments both ways, but perhaps the most
telling argument is that Inform designers seem pretty happy with the
present arrangement, and seldom avail themselves of the option to
have adjectives, which as you say is pretty simple to add to the
system.
Julian Arnold
Magnus Olsson
In article <ant2521051cbM+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>In article <60djfr$f8v$1...@bartlet.df.lth.se>, Magnus Olsson
>> The distinction between nouns and adjectives can be very helpful,
>> for example to avoid things like
>>
>> > examine cat
>>
>> Which cat do you mean, the black cat, the cat food, or the tin of
>> cat food?
>>
>> By making cat an "adjective" for the cat food and the tin, but
>> a "noun" for the black cat, you can avoid the ambiguity.
>
>Umm. Yes, I never know whether the decision to opt for a purely
>noun-based parser was a brilliantly elegant coup of simplification
>or a dunderheaded lack of imagination. Somewhere in between,
>I expect.
Somewhere in between, yes. :-)
> I can see arguments both ways, but perhaps the most
>telling argument is that Inform designers seem pretty happy with the
>present arrangement, and seldom avail themselves of the option to
>have adjectives, which as you say is pretty simple to add to the
>system.
With all respect, I think that argument is pretty bad. You should
be asking _players_, not _writers_, because it's the players who
get inconvenienced by disambiguation silliness like the cat food
thing above.
As a writer, I find it convenient just to put all the words I can
think of into the "name" property:
object cat_food_tin "tin of cat food"
with
name 'tin' 'of' 'cat' 'food'
;
but as a player, I tend to get very irritated by constantly having to
remind the parser that when I say just "cat", I mean the animal, not
anything that just happens to have the word "cat" as part of its name.
To turn this into a concrete proposal, I think you should add support
for adjectives to the Library. If it's done in a manner similar to the
way suggested in the Manual, this wouldn't break any existing code,
and authors would be free not to use them. As for internalization,
at least Indo-European languages seem to inflect adjectives in the same
way as nouns (governed by the case and gender of the noun they belong
to).
Will Grzanich
Magnus Olsson wrote:
> As a writer, I find it convenient just to put all the words I can
> think of into the "name" property:
>
> object cat_food_tin "tin of cat food"
> with
> name 'tin' 'of' 'cat' 'food'
> ;
>
> but as a player, I tend to get very irritated by constantly having to
> remind the parser that when I say just "cat", I mean the animal, not
> anything that just happens to have the word "cat" as part of its name.
I'd have to agree here. There's a big problem which can come
up--namely, if you've got an object with the name property "cat", and
another with "tin" "of" "cat" "food", then it is strictly impossible to
do anything with the "cat" itself! The adname library extension handles
this sort of thing quite nicely, but it would be more convenient to have
it built into the core libraries--perhaps let each object have an
"adjective" *and* a "name" property, so things can be done the old way,
too.
-Will
--
"All you need is love." | Check out my cheeky webpage at
-John Lennon | www.cen.uiuc.edu/~grzanich!
| Lemony fresh!
Graham Nelson
In article <60e9m7$f...@wanda.vf.pond.com>, Matthew T. Russotto
<URL:mailto:russ...@wanda.vf.pond.com> wrote:
>
> It's trying to access object 0's name, IIRC. Results are undefined.
> And this is something of a low blow because it's just a bug, not a serious
> parser shortcoming. Zork I sidestepped the problem by having "it" be
> the mailbox initially.
Yes, you're quite right. It's just that I was a teeny bit
unimpressed that it could do that in reply to the very first thing
I tried. And it's not as if the Inform parser has never contained
bugs...
(The "Zork I" thing is amusing -- for years I thought the Z1 parser
was automatically setting "it" to a sensible nearby object. But
no.)
To put the record straight, I wasn't grandiloquising about the
Inform parser, or trying to denigrate the Infocom one -- just making
the point that Infocom's parsers varied quite a lot in quality,
and that some of them wouldn't be too impressive in a modern game.
Andrew Plotkin
> > As a writer, I find it convenient just to put all the words I can
> > think of into the "name" property:
> >
> > object cat_food_tin "tin of cat food"
> > with
> > name 'tin' 'of' 'cat' 'food'
> > ;
> >
> > but as a player, I tend to get very irritated by constantly having to
> > remind the parser that when I say just "cat", I mean the animal, not
> > anything that just happens to have the word "cat" as part of its name.
> I'd have to agree here. There's a big problem which can come
> up--namely, if you've got an object with the name property "cat", and
> another with "tin" "of" "cat" "food", then it is strictly impossible to
> do anything with the "cat" itself!
Maybe a "percentage of name match" factor in the resolution, so "cat"
(100% of words matched) would be favored over "tin of cat food" (25%.)
But a noun/adjective separation is probably more controllable.
One thing I must add, however, is that it should be *possible* to name an
object with only the adjectives. That is, if only the can is present, you
should be able to refer to it as "cat". I seem to recall that I can't do
this in TADS games, and it really annoys me.
(Why do I want this? Well, say there's a cat, a dog, a tin of cat food,
and a tin of dog food. If all four are present, I'm going to type "get
cat food". But if only the two cans are present, I'm going to type "get
cat", since that's unambiguous.)
> The adname library extension handles
> this sort of thing quite nicely, but it would be more convenient to have
> it built into the core libraries--perhaps let each object have an
> "adjective" *and* a "name" property, so things can be done the old way,
> too.
It would make some things more complicated, even on the user side. The
parse_name property would have to return more information, for example. I
think I prefer it as an extension.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Stephen Granade
On Fri, 26 Sep 1997, Andrew Plotkin wrote:
> One thing I must add, however, is that it should be *possible* to name an
> object with only the adjectives. That is, if only the can is present, you
> should be able to refer to it as "cat". I seem to recall that I can't do
> this in TADS games, and it really annoys me.
Sometimes you can, and sometimes you can't. The whys and wherefores are
hidden deep within the TADS source.
Stephen
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Check out
Duke University, Physics Dept | http://interactfiction.miningco.com
Julian Arnold
This is a repost as the original got eaten by a grue.
BTW, this post isn't totally pro-Hugo, but I think the Hugo approach
does have certain benefits, although it isn't perfect.
In article <60djfr$f8v$1...@bartlet.df.lth.se>, Magnus Olsson
<URL:mailto:m...@bartlet.df.lth.se> wrote:
> [...]
> The distinction between nouns and adjectives can be very helpful,
> for example to avoid things like
>
> > examine cat
>
> Which cat do you mean, the black cat, the cat food, or the tin of
> cat food?
>
> By making cat an "adjective" for the cat food and the tin, but
> a "noun" for the black cat, you can avoid the ambiguity.
While in Hugo nouns always have precedence over adjectives for
disambiguation purposes, you can also give any object a parse_rank
property--the higher the object's parse_rank, the greater preference is
given that object in cases of ambiguity resolution. By default an object
without an explicit parse_rank property has an implicit rank of 1. Thus,
in Hugo, if the three objects were set up as suggested:
object cat_food
{
adjective "cat"
noun "food"
}
object tin_of_cat_food
{
adjectives "tin", "cat"
noun "food"
}
character cat
{
adjective "black"
noun "cat"
}
"examine cat" would pick the cat automatically, but "examine food" would
still result in "Which do you mean..." (as "food" is a noun for both the
1st and 2nd objects). To have this ambiguity resolved automatically you
would code the 1st object as:
object cat_food
{
adjective "cat"
noun "food"
parse_rank 10 ! any # will do, as long as it's higher
} ! than the other objects'.
Now "... food" will automatically pick the cat food, not the tin.
However, so will "... cat food" or "... cat" (assuming the cat itself
has wandered out of scope).
To get round this you have to make the parse_rank verb-sensitive, as in:
object tin_of_cat_food
{
adjectives "tin", "cat"
noun "food"
parse_rank {
if verbroutine = &DoOpen
return 20
else
return 1
}
}
Now "open cat food" will choose the tin, while any other verb will
choose the food.
A problem with this system is that by having the unintelligent computer
resolving ambiguities the player is more likely to make unfortunate
errors. For instance, say the player typed "hit cat food," meaning the
tin, but forgetting the food was nearby too. A "which do you mean..."
message would notify him of the potential mistake before any damage was
done. Thanks to parse_rank though he'd quickly be covered in cat food
whereas all he expected was a bruised knuckle. So in some circumstances
it may be useful to keep the parse_ranks equal.
Also, juggling the parse_ranks to avoid conflict and/or illogicality
becomes a nightmare with more than a very few similarly named objects.
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me
from ever completing anything." -- Herman Melville, "Moby Dick"
Magnus Olsson
In article <ant26194...@arnod.demon.co.uk>,
Julian Arnold <jo...@arnod.demon.co.uk> wrote:
>In article <60djfr$f8v$1...@bartlet.df.lth.se>, Magnus Olsson
><URL:mailto:m...@bartlet.df.lth.se> wrote:
>> [...]
>> The distinction between nouns and adjectives can be very helpful,
>> for example to avoid things like
>>
>> > examine cat
>>
>> Which cat do you mean, the black cat, the cat food, or the tin of
>> cat food?
>>
>> By making cat an "adjective" for the cat food and the tin, but
>> a "noun" for the black cat, you can avoid the ambiguity.
>
>While in Hugo nouns always have precedence over adjectives for
>disambiguation purposes, you can also give any object a parse_rank
>property--the higher the object's parse_rank, the greater preference is
>given that object in cases of ambiguity resolution.
This approach certainly has its merits (and Inform has a similar,
though cruder, mechanism in the ChooseObjects routine). Also, the
"parse rank" should really depend on the action being contemplated,
shouldn't it?
But, as Jools points out, it also has its drawbacks and pitfalls.
I think the simple approach of "adjectives" vs. "nouns", or perhaps
the only slightly more complicated one of "adjectives" and "nouns" vs.
"particles" (which I'll describe in more detail below) is a very
significant advance over the standard Inform "everything is a noun"
approach, both because it will eliminate most of the "cat food"
problems, and because it closely parallels the way natural language
works. It also has the advantage of being simple, both to implement
and to use!
A linguistic excursion:
What's the difference between the word "cat" in the names "cat food"
and "black cat"? Strictly speaking, it's a noun in both cases (which
is why I prefer to write "nouns" and "adjectives" in quotes above -
the usage is a bit non-standard).
But in the case of the black cat, "cat" is the main word, the
important name of the animal, while in the case of the cat food, "cat"
is an attribute - the important word is "food", "cat" just qualifies
it and tells us what kind of food it is.
By labeling some of the nouns associated with an object as
"adjectives" (in the non-standard sense), we're telling the parser
that they're being used as attributes, as qualifiers to the words
marked as "nouns".
I wrote something above about "particles" as well. That would be words
like the "of" in "tin of cat food". The adventure parser should
recognize them as parts of the name, but they should never be
recognized on their own (which adjectives may be). Because otherwise
we could get strange things like this:
> take of [ really, a misspelling of "take off" ]
Which of do you want to take, the tin of cat food, the wand of death,
or the Akond of Swat?
***
To summarize, what I'm suggesting is that each object in an Inform
game be given three properties to hold its vocabulary words:
object "tin of cat food"
with
name 'food' 'tin',
adjective 'cat',
particle 'of'
;
Will Grzanich
Magnus Olsson wrote:
>
> To summarize, what I'm suggesting is that each object in an Inform
> game be given three properties to hold its vocabulary words:
>
> object "tin of cat food"
> with
> name 'food' 'tin',
> adjective 'cat',
> particle 'of'
> ;
I think this would be absolutely terrific. Don't know how hard it would
be to add to the libraries, or what problems (if any) might arise as a
result of its implementation, but I like it.
Mark J Musante
Andrew Plotkin (erky...@netcom.com) wrote:
> One thing I must add, however, is that it should be *possible* to name an
> object with only the adjectives. That is, if only the can is present, you
> should be able to refer to it as "cat". I seem to recall that I can't do
> this in TADS games, and it really annoys me.
*sputter* *sputter* But you can!
If I create two objects:
red_gizmo: item
noun = 'gizmo'
adjective = 'red'
sdesc = "red gizmo"
;
blue_gizmo: item
noun = 'gizmo'
adjective = 'blue'
sdesc = "blue gizmo"
;
I can say "get red" or "get blue" to pick them up.
-=- Mark -=-
Neil K.
In article <erkyrathE...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) wrote:
> One thing I must add, however, is that it should be *possible* to name an
> object with only the adjectives. That is, if only the can is present, you
> should be able to refer to it as "cat". I seem to recall that I can't do
> this in TADS games, and it really annoys me.
Well, under normal circumstances in TADS, you can refer to an object with
its adjective only and it works. No problem.
The one case where it is a problem is if you have an object with a
vocabulary word (say, 'steel') as an adjective, and that word also happens
to be defined elsewhere in the game as a noun. In that case you can't use
that one adjective to refer to the thing. If you type "get steel" when
both objects are in the room you'll be given the item with steel as a
noun, as it should be. But if the noun object is not visible and the
adjective object is, "get steel" yields "I don't see that here."
There was one instance of this problem that I reported to Mike Roberts,
and which he fixed in version 2.2:
> - The parser did not previously accept a word during disambiguation
> if the word was defined as both a noun and an adjective. For
> example, if you've defined objects "violet paper", "violet banana",
> and "paper towel", and the parser asked you this:
>
> >x violet
> Which violet do you mean, the violet paper, or the violet banana?
>
> then you couldn't respond with "paper". This has been corrected.
Unfortunately, although he fixed that for the disambiguation phase he
didn't fix it generally. Oh well.
Aside from this one glitch I very much prefer being able to specify
adjectives. Gives one a lot more flexibility over things.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Kenneth Albanowski
In article <34274C...@netins.net>,
Paul Fernhout <kfs...@netins.net> wrote:
>
>I created an eight room / two object demo adventure program (in Delphi,
>using Microsoft Whisper Speech Recognizer and Monologue TTS) that you
>could say one word commands and the system would speak your location
>information and play some sound effects (take and drop just worked on
>the first thing on the ground or in inventory). You didn't have to look
>at a monitor or use a keyboard to play the ten minute game. Would
>support for something like this be compelling enough to make people
>learn a new development system in Smalltalk (probably only running under
>Win32)? [I guess this could be added to Inform too of course - like
>using $99 IBM ViaVoice and the free developer kit].
Let me take a moment to espouse one of my ideas: speech interfaces are crude
things as the moment, and often poorly thought out (consider a blind person
trying to use IBM dictation software, or even just the minor inanity of
"begin dictation"/"stop dictation", instead of begin/end or start/stop.)
Since the basic rules of IF seem to easily translate to a speech based
system (you have a reasonably static "room", can examine objects in the
room, use objects, transit to other rooms, there is a limited vocabulary,
etc.) I wonder whether a decent speech interface to other pieces of software
could be designed using the IF paradigm, essentially as a "back channel", to
get a different view of the current task.
Consider a word processor with an open file, a paragraph, and a word
selected:
> WHAT IS HERE
"You are looking at page 15 of document QED, with the word FOO selected"
> MAKE IT BOLD
"Bold"
> SELECT THE PARAGRAPH
"Paragraph selected"
> SAVE FILE
"Saved"
> REVERT FILE
"Confirmation needed to revert file" (opens dialog)
At this point, you can start mixing channels, just as you currently can mix
mouse clicks and keyboard clicks. Maybe you just set up a few voice macros
(instead of all those icons or key codes) to perform common operations, or
conversely you set up a mouse or keybord operation to return information
(the current page or word count, say) via voice.
Getting back to the dialog:
> EXAMINE PARAGRAPH
"The current paragraph has fifty words and three sentences"
> SUMMARIZE IT
"It starts with 'When I was a tadpole'"
[the user doesn't give a voice command for five minutes]
> SUMMARIZE IT
"By 'it', I assume you mean the current paragraph. It starts with 'When I
was a tadpole'"
[the user moves the cursor]
> CUT THIS PARAGRAPH
"Cutting the current paragraph"
And so on. As you can see, I'm of the opinion that most IF UI techniques are
almost directly applicable to voice control (sometimes called "navigation"),
with the caveat that past responses aren't visible, so more "assumption
reminders" are needed.
--
Kenneth Albanowski (kja...@kjahds.com)
Will Grzanich
Andrew Murie wrote:
> The library adname.h by Andrew Clover does this. You would define the
> cat food object similar to the above suggestion. Then you could refer to it
> as "cat food" or "food" but the word "cat" on its own would refer to the cat.
I know about adname.h. It's quite good. But I'd like to see it as an
integral part of the language.
Andrew Murie
Will Grzanich (grza...@uiuc.edu) wrote:
: Magnus Olsson wrote:
: >
: > To summarize, what I'm suggesting is that each object in an Inform
: > game be given three properties to hold its vocabulary words:
: >
: > object "tin of cat food"
: > with
: > name 'food' 'tin',
: > adjective 'cat',
: > particle 'of'
: > ;
:
: I think this would be absolutely terrific. Don't know how hard it would
: be to add to the libraries, or what problems (if any) might arise as a
: result of its implementation, but I like it.
The library adname.h by Andrew Clover does this. You would define the
cat food object similar to the above suggestion. Then you could refer to it
as "cat food" or "food" but the word "cat" on its own would refer to the cat.
The library is available at ftp.gmd.de in the directory :
/if-archive/infocom/compilers/inform5.5/library/contributions
Thomas Aaron Insel
Will Grzanich <grza...@uiuc.edu> writes:
> Andrew Murie wrote:
> > The library adname.h by Andrew Clover does this. You would define the
> > cat food object similar to the above suggestion. Then you could refer to it
> > as "cat food" or "food" but the word "cat" on its own would refer to the cat.
> I know about adname.h. It's quite good. But I'd like to see it as an
> integral part of the language.
I'm using adname.h, and like it, but the behavior I'd like to see is
something like this: Consider three objects,
cat with name cat,
cat food with name food, adjective cat,
cat collar with name collar, adjective cat,
if all three are in scope, "cat" means cat, if only cat food is in
scope, then "cat" means cat food, and if cat food and cat collar are
in scope, but not cat, then the player is asked to disambiguate
between cat food and cat collar.
Does anyone understand what I mean? And, does anyone know how to
implement this? It seems much harder than adname's approach, but I
think it would really improve interaction.
Tom
--
Thomas Insel (tin...@jaka.ece.uiuc.edu)
"I regret to say that we of the FBI are powerless to act in cases of oral-
genital intimacy, unless it has in some way obstructed interstate commerce."
-- J. Edgar Hoover
Miron Schmidt
Thomas Aaron Insel <tin...@jaka.ece.uiuc.edu> wrote:
> Consider three objects,
> cat with name cat,
> cat food with name food, adjective cat,
> cat collar with name collar, adjective cat,
> if all three are in scope, "cat" means cat, if only cat food is in
> scope, then "cat" means cat food, and if cat food and cat collar are
> in scope, but not cat, then the player is asked to disambiguate
> between cat food and cat collar.
>
> Does anyone understand what I mean? And, does anyone know how to
> implement this? It seems much harder than adname's approach, but I
> think it would really improve interaction.
I've done that. I'll upload the enhanced library after I've cleaned the code
up and written a short intruction page.
(The way I do it is to throw out the rule about only accepting input with one
noun, but giving the object in question an additional attribute which I can
then query in ChooseObjects() or some similar routine.)
--
Miron Schmidt <mi...@comports.com> PGP key on request
WATCH TV... MARRY AND REPRODUCE... OBEY... PLAY INTERACTIVE FICTION...
John Francis
In article <tinsel.8...@jaka.ece.uiuc.edu>,
>
>> Andrew Murie wrote:
>
>> > The library adname.h by Andrew Clover does this. You would define the
>> > cat food object similar to the above suggestion. Then you could refer to it
>> > as "cat food" or "food" but the word "cat" on its own would refer to the cat.
>
>> I know about adname.h. It's quite good. But I'd like to see it as an
>> integral part of the language.
>
>I'm using adname.h, and like it, but the behavior I'd like to see is
> cat with name cat,
> cat food with name food, adjective cat,
> cat collar with name collar, adjective cat,
>if all three are in scope, "cat" means cat, if only cat food is in
>scope, then "cat" means cat food, and if cat food and cat collar are
>in scope, but not cat, then the player is asked to disambiguate
>between cat food and cat collar.
>
>Does anyone understand what I mean? And, does anyone know how to
>implement this? It seems much harder than adname's approach, but I
>think it would really improve interaction.
I have never been able to understand why many authors put so much
importance on the ability to refer to an object by just an adjective.
It doesn't seem like a natural use of language to me. I never had
any problem typing "TAKE BLUE CAKE" or "TAKE EATME CAKE" - I never
thought to try "TAKE BLUE" (just as well - it probably wouldn't
have worked on a real Infocom parser, anyway).
I only became aware of the fact that you could omit the noun when
I was playing around in a game that incorporated oak and balsa beams.
There was a bug in the parser in an earlier version of the game which
made it impossible to refer to these as "OAK BEAM" or "BALSA BEAM",
so I was stuck with an insoluble puzzle. But some people were
obviously able to solve the problem and complete the game.
I eventually resorted to looking at a walkthrough, and was
rather astonished to see "PUT OAK IN ..."
I would expect
> TAKE CAKE
Which cake do you want to take? The red one or the blue one?
> BLUE
to work, but I don't see why "TAKE BLUE" has to. I think the
implementers got it right originally when they differentiated
between nouns and adjectives - failing to do so in Inform was
a great technological leap backwards (in my opinion, of course).
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Unsolicited electronic mail will be subject to a $100 handling fee.
Julian Arnold
In article <61dtde$1t...@fido.asd.sgi.com>, John Francis
<URL:mailto:jfra...@dungeon.engr.sgi.com> wrote:
> I have never been able to understand why many authors put so much
> importance on the ability to refer to an object by just an adjective.
> It doesn't seem like a natural use of language to me. I never had
> any problem typing "TAKE BLUE CAKE" or "TAKE EATME CAKE" - I never
> thought to try "TAKE BLUE" (just as well - it probably wouldn't
> have worked on a real Infocom parser, anyway).
One important consideration is the player's patience. When confronted
with "three nematophores, one red, one blue, and one green" I'd want to
be able to refer to them by colour, and not have to type out nematophore
every time, as it is quite a long word (the other consideration here is
if the noun word is hard to spell, an easier adjective is nice to have).