idea for text adventure user-interface
michael...@ey.com
[This was in response to an article posted on rec.games.int-fiction. I
thought maybe it more properly belonged here? Anyway, it might provoke some
interesting discussion.]
In article <35779945...@but.be>,
Tom Alaerts <to...@but.be> wrote:
>
> Hello,
>
> while I discovered adventure games years ago playing zork on a apple 2,
> in recent years i have grown to appreciate the lucasarts style of
> interface. The first graphical adventure i played was indiana jones in
> atlantis. I thought it was excellent and believe the user interface with
> just a few words to click on wasn't limiting.
> So, what do you people think of the idea of a text adventure with a
> similar, reduced set of verbs?
> I was actually thinking of making my first text adventure and using a
> similar vocabulary. For example, instead of handling specific verbs like
> "uncork" etc., you would be able to do everything with "use".
> Curious what you think of it.
>
Good idea, perhaps, for graphics-based adventures; bad idea, I think, for text
based.
Here's my own personal gripe -- one of the charms of any text adventure game
is its use of language as an interface. The wide variety of verbs and
phraseology available to the player perpetuates the illusion that the player
is "communicating" with the story, and that the story is responding to the
player. We all know that that's not what's really going on, of course, but a
flexible and versatile parser allows us to suspend our disbelief.
When you restrict the parser -- when you force the player to abstract the
language -- you break that bubble of disbelief. There's no sense of
communication. The game is reduced to a panel of buttons -- a button labelled
"Take", a button labelled "Drop", a button labelled "Examine" -- and the
player is reduced to simply figuring out what sequence to push them in.
Let's take a loo>
<input type=
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
L. Ross Raszewski
In article <6l9f73$h65$1...@nnrp1.dejanews.com>,
michael...@ey.com wrote:
>
> When you restrict the parser -- when you force the player to abstract the
> language -- you break that bubble of disbelief. There's no sense of
> communication. The game is reduced to a panel of buttons -- a button labelled
> "Take", a button labelled "Drop", a button labelled "Examine" -- and the
> player is reduced to simply figuring out what sequence to push them in.
My problem with this explanation is that it makes out the difference between
a parser and a more restricted format ot simply be a differece in scale; a
button panel has 3 choices, a text parser has a hundred or so.
You could just as easily say that all a parser does is reduce a plaer's job to
working out in what sequence to use a set of words
michael...@ey.com
[Yaaah!!! Let's try that again, okay?]
In article <35779945...@but.be>,
Tom Alaerts <to...@but.be> wrote:
>
> Hello,
>
> while I discovered adventure games years ago playing zork on a apple 2,
> in recent years i have grown to appreciate the lucasarts style of
> interface. The first graphical adventure i played was indiana jones in
> atlantis. I thought it was excellent and believe the user interface with
> just a few words to click on wasn't limiting.
> So, what do you people think of the idea of a text adventure with a
> similar, reduced set of verbs?
> I was actually thinking of making my first text adventure and using a
> similar vocabulary. For example, instead of handling specific verbs like
> "uncork" etc., you would be able to do everything with "use".
> Curious what you think of it.
>
Good idea, perhaps, for graphics-based adventures; bad idea, I think, for text
based.
Here's my own personal gripe -- one of the charms of any text adventure game
is its use of language as an interface. The wide variety of verbs and
phraseology available to the player perpetuates the illusion that the player
is "communicating" with the story, and that the story is responding to the
player. We all know that that's not what's really going on, of course, but a
flexible and versatile parser allows us to suspend our disbelief.
When you restrict the parser -- when you force the player to abstract the
language -- you break that bubble of disbelief. There's no sense of
communication. The game is reduced to a panel of buttons -- a button labelled
"Take", a button labelled "Drop", a button labelled "Examine" -- and the
player is reduced to simply figuring out what sequence to push them in.
Let's take a look at the word "use", for example. "Use" is about as abstract
as it gets. It renders moot the entire issue of languag>
<input type=
Bill
L. Ross Raszewski wrote in message <6l9ie0$lmc$1...@nnrp1.dejanews.com>...
>In article <6l9f73$h65$1...@nnrp1.dejanews.com>,
> michael...@ey.com wrote:
>>
>> When you restrict the parser -- when you force the player to abstract the
>> language -- you break that bubble of disbelief. There's no sense of
>> communication. The game is reduced to a panel of buttons -- a button
labelled
>> "Take", a button labelled "Drop", a button labelled "Examine" -- and the
>> player is reduced to simply figuring out what sequence to push them in.
>
>My problem with this explanation is that it makes out the difference
between
>a parser and a more restricted format ot simply be a differece in scale; a
>button panel has 3 choices, a text parser has a hundred or so.
There's a big difference. You DON'T KNOW what the verb choices are with a
text parser. That adds a great deal to the "suspension of disbelief" that
you have "infinite posibilities" in the game.
Can a graphical interface achieve this? In RTZ (Return to Zork) we changed
what "verbs" were available on a case by case basis. This added a sense of
"novelty" but didn't address the "infinte possibilities" of a text parser.
I'm interested in a RT3D game because I think "physical" puzzles could be
solved via. a graphical interface that WOULD have "infinite possibilties"
... think of "The Incredable Machine" style of puzzle.
Take the opening scene of the film "Raiders of the Lost Ark." You see a
gold statue sitting on a platform. You have a bag and some sand. You can
add or remove sand from the bag ... even get a "feel" for what it weights
(wouldn't force freedback controls be ideal for that?). When you think
you've got it right ... you swap it for the statue. Hopefully you're
luckier than Indy was....
I also think the area of NPC interaction is ripe with possibilities. I had
hoped that Starship Titanic was going to be the ground-breaking title in
terms of supporting conversations ... but I am told that this is not the
case.
We've got excellent speech recognition stuff, but the real challenge is
still the "conversation parser." I don't think Starship's parser is the
issue. It's the problem of representing character knowledge and modeling
behavior that makes this hard.
Anyway, back to the world of educational software.
Bill Volk
michael...@ey.com
In article <6l9ie0$lmc$1...@nnrp1.dejanews.com>,
L. Ross Raszewski <rras...@hotmail.com> wrote:
>
> In article <6l9f73$h65$1...@nnrp1.dejanews.com>,
> michael...@ey.com wrote:
> >
> > When you restrict the parser -- when you force the player to abstract the
> > language -- you break that bubble of disbelief. There's no sense of
> > communication. The game is reduced to a panel of buttons -- a button
labelled
> > "Take", a button labelled "Drop", a button labelled "Examine" -- and the
> > player is reduced to simply figuring out what sequence to push them in.
>
> My problem with this explanation is that it makes out the difference between
> a parser and a more restricted format ot simply be a differece in scale; a
> button panel has 3 choices, a text parser has a hundred or so.
>
> working out in what sequence to use a set of words
Well, not exactly. Like I said, the illusion of communication is just that --
an illusion, a suspension of disbelief. When all of your available verbs are
right there on a ten-item pulldown menu, the suspension of disbelief is
quickly shattered.
When you have a suite of something like 70 or 80 standard verbs, it's a
little easier to lose yourself in the language. Add to that the 50 or 60
extra verbs and synonyms (if it's a really good game) that the author has
implemented in order to handle specific situations and to enrich the overall
atmosphere, and add to that the many different ways you can phrase your
command (GIVE MONEY TO BEGGAR; GIVE THE BEGGAR SOME MONEY; BEGGAR, TAKE THE
MONEY; etc.) -- the permutations quickly pile up. The "list" becomes
something that can't easily fit on a menu or in your head -- you have to
explore it. The goal is to have a space large enough for your imagination to
roam> <input type=
michael...@ey.com
Okay, this is pissing me off. Sorry about the repetition, everybody. Here's
the second half of my mini-essay on the "plain-English" parser vs. a dropdown
menu style. If this doesn't post right, I'm gonna strangle someone.
****
Let's take a look at the word "use", for example. "Use" is about as abstract
as it gets. It renders moot the entire issue of language -- it makes almost
any verb unnecessary. USE COAT (wear it). USE BANANA (eat it). USE SWORD
(whack the nearest enemy with it). USE BOX (open it if it's closed, close it
if it's open). There's no real need to draw the line anywhere -- a perfectly
logical extrapolation would be to type USE QUEST (win it) at the very
beginning of the game and have done with it.
Like somebody else on this thread noted, I'll type OPEN BOTTLE, UNCORK BOTTLE,
PULL CORK or a hundred other variations before it occurs to me to USE BOTTLE.
(Besides, what if I wanted to USE the bottle by smashing it over a guard's
head? or weighing down a stack of papers? or sticking a message into it and
tossing it into the ocean?) These are natural responses, communicating through
language.
If you're designing a text adventure, grit your teeth and start making a list
of verbs. Your game will be much more enjoyable.
--M.
Roger Carbol
Bill wrote:
> There's a big difference. You DON'T KNOW what the verb choices are with a
> text parser. That adds a great deal to the "suspension of disbelief" that
> you have "infinite posibilities" in the game.
True, in general, most textual IF does not provide a list of valid
(or interesting) verbs for any given situation. It certainly could,
and I seem to recall that a game called something like "Enchanter 101"
did display a list of verbs -- the game had a graphic component, but
it was essentially a text interface, and the graphics could be
switched off entirely.
In any case, it's usually seen as a fault in any type of IF when
the user isn't aware of the valid verb choices (as opposed to not
being aware of valid actions.) It leads us into the common
"guessing-the-verb" problem.
I seem to recall that some Infocom documentation did, in fact,
provide a list of 'common' verbs. I'm not sure, but I suspect
every game could be solved using only verbs from that list, with
certain specialized exceptions such as using verbs as spells
(although I seem to recall that syntax such as "CAST FROTZ ON ME"
would work.)
In general, then, I think that the illusion of infinite possibility
to which you refer is: 1) a rather unconvincing illusion at best,
and 2) an illusion which may be more irritating than enjoyable.
Or such is my opinion.
.. Roger Carbol .. r...@shaw.wave.ca .. triage the ward
William Volk
Roger Carbol wrote in message <357863...@shaw.wave.ca>...
>In any case, it's usually seen as a fault in any type of IF when
>the user isn't aware of the valid verb choices (as opposed to not
>being aware of valid actions.) It leads us into the common
>"guessing-the-verb" problem.
and...
>In general, then, I think that the illusion of infinite possibility
>to which you refer is: 1) a rather unconvincing illusion at best,
>and 2) an illusion which may be more irritating than enjoyable.
>Or such is my opinion.
Ideally the verb that's needed in a situation should make sense once
discovered and used. If the puzzle seems arbitrary and the game a "guess
the verb" annoyance, then the authors have failed.
Bill
Joe Mason
Roger Carbol wrote:
>
> In general, then, I think that the illusion of infinite possibility
> to which you refer is: 1) a rather unconvincing illusion at best,
> and 2) an illusion which may be more irritating than enjoyable.
> Or such is my opinion.
I agree that the illusion of *infinite* possibility is neither feasible
nor desirable. What's needed is a wide enough variety that that the
possibilities do not seem limiting.
I'm playing Zork Nemesis right now, and although I love the atmosphere,
I don't think its POSSIBLE that it could compete with a parsed adventure
in gameplay. I started Anchorhead at the same time, and every time I
had the urge to sit down and play "an adventure" I turned to Anchorhead
first because it was more immersive.
The reason is that ZN's simple point-and-click style brings the
limitations on what the player can do into the forefront, while the
parser downplays them as much sa is feasable. I think any successful
system would need to provide a fairly wide variety of possible actions
in every situation, rather than allowing a single action at each area as
ZN does.
I was very disappointed that Activision dropped the Return to Zork
interface, which I thought was the best part of the game. It was, I
think, a great way to give many options in each situation while keeping
the interface streamlined and easf to use. In ZN, I constantly think,
"They really put a lot of effort into the production values of this, and
most of the details came out just right - but the framework they're
building on prevents it from being a great game." With RTZ, I was
constantly thinking, "If they'd gotten the details right, this could
have been a great game."
Joe
Roger Carbol
Joe Mason wrote:
> I agree that the illusion of *infinite* possibility is neither feasible
> nor desirable. What's needed is a wide enough variety that that the
> possibilities do not seem limiting.
On the other hand, I think we've all played those games where we
reach a point of overwhelming possibility. Where we could walk to
any of three dozen locations and manipulate twice that many objects.
So it's my opinion that the *right* amount of possibility-limiting
is the correct way to consider the issue.
> I was very disappointed that Activision dropped the Return to Zork
> interface, which I thought was the best part of the game. It was, I
> think, a great way to give many options in each situation while keeping
> the interface streamlined and easf to use. In ZN, I constantly think,
> "They really put a lot of effort into the production values of this, and
> most of the details came out just right - but the framework they're
> building on prevents it from being a great game." With RTZ, I was
> constantly thinking, "If they'd gotten the details right, this could
> have been a great game."
Could you briefly summarize the RTZ interface? Thanks.
.. Roger Carbol .. r...@shaw.wave.ca .. return to nemesis
Roger Carbol
William Volk wrote:
> Ideally the verb that's needed in a situation should make sense once
> discovered and used. If the puzzle seems arbitrary and the game a "guess
> the verb" annoyance, then the authors have failed.
I agree, of course. I just think that providing a list of verbs
which a particular game has implemented is not a bad thing.
.. Roger Carbol .. r...@shaw.wave.ca .. debride the wound
Bill
Roger Carbol wrote in message <357C09...@shaw.wave.ca>...
>William Volk wrote:
>
>> Ideally the verb that's needed in a situation should make sense once
>> discovered and used. If the puzzle seems arbitrary and the game a "guess
>> the verb" annoyance, then the authors have failed.
>
>I agree, of course. I just think that providing a list of verbs
>which a particular game has implemented is not a bad thing.
Obviously you are required to do this in a graphical interface.
BUT my point restated is this .... an "ideal" text adventure can create an
illusion of infinite possibilities PRECISELY by the hiding of the verb list
IF the system responds to resonable commands in a resonable manner, and if
the puzzles are NOT of the "guess the verb" possibility.
My goal for a graphical interface is to attempt to recapture that "feeling"
that I had when I first sat down with Zork (the original) on a 300 Baud
TV-Typewriter connected to what was known as APRA-Net. The feeling was that
I could "go anywhere, do anything." An illusion but it felt great!
Adventures have not had a good time in the marketplace as of late. I
believe the reason is that the "industry" has forgetten what was "magic"
about adventures in the first place.
Bill Volk
L. Ross Raszewski
In article <X3ff1.12181$Kx3.12...@news.rdc1.sdca.home.com>,
"Bill" <bv...@inetworld.net> wrote:
>
> Obviously you are required to do this in a graphical interface.
>
> BUT my point restated is this .... an "ideal" text adventure can create an
> illusion of infinite possibilities PRECISELY by the hiding of the verb list
> IF the system responds to resonable commands in a resonable manner, and if
> the puzzles are NOT of the "guess the verb" possibility.
>
> believe the reason is that the "industry" has forgetten what was "magic"
> about adventures in the first place.
I think you make a lot of really good points here (some of whichg I snipped
out), but I'm not entirely sure I see it your way.
You see, as I see it, the text adventure (and all adventure systems, but in
differing ways that would have to be explained very differently, and probably
by someone with the financial resources to have played quite a lot more of
them than I have) uses an interface that forms an agreement with the player
which is this:
---The Parser's Credo---
I will provide you with an immersive world.
I will allow you to go anywhere, do anything you could in reality.
I will accept any sentence, understand it, and do what you like.
I will understand you.
In return, you will restrict your actions to the scope of this game.
You will form your instructions in the format I understand.
You will use only the words this game provides.
You will not attempt to press the boundaries of the game world
---
THe problem is that we put too much emphasis on the first part of this credo,
and too little on the second.
And the problem is not that parsers are failing their end of the bargain, but
that we are _unable_ to meet our end.
And if _we_ don't, mimesis is broken.
It's an imperfect arrangement. And some of us would prefer a less pressing
one-- one where the parser is asked to do less, and in return, the player is
forced to jump through fewer hoops. To me, at least, the parser's credo
swears the parser to maintain a lie, and the player not to challenge it.
But the player is ALWAYS going to challenge the parser, so perhaps if we start
expecting less from the interface, the interface will, in return, expect less
from us, and we won't be disappointed as often.
What I'm suggesting _isn't_ the bastardization of an ideal interface -- it's
opting for a different balance of power; both methods have advantages, and
disadvantages, and I sincerely doubt that one is proveably better than the
other.
Joe Mason
Roger Carbol wrote:
>
> > I was very disappointed that Activision dropped the Return to Zork
> > interface, which I thought was the best part of the game. It was, I
> > think, a great way to give many options in each situation while keeping
> > the interface streamlined and easf to use. In ZN, I constantly think,
> > "They really put a lot of effort into the production values of this, and
> > most of the details came out just right - but the framework they're
> > building on prevents it from being a great game." With RTZ, I was
> > constantly thinking, "If they'd gotten the details right, this could
> > have been a great game."
>
> Could you briefly summarize the RTZ interface? Thanks.
Well, first off it involved hotspots on the screen. Moving the cursor
near the edge, or on a doorway or other enterable object, would turn it
into an arrow allowing movement. Certain hot spots would allow you to
zaam in, getting a more detaileh view of an object. And items which
could be interacted with gave an "interact with me" cursor. If you had
an object in hand (in which case your cursor was a picture of the
object) the interaction would involve both objects. So far, pretty much
the same as Zork Nemesis.
The good part of the interface was that when you clicked the interaction
hotspot you would get an iconic menu of possible actions. The standard
ones were included things like "pick up", "drop", "put in", etc. but
each object could extend the menu with its own. For example, the very
first puzzle involved a plant growing at the base of a sign. The
standard menu included "pick bonding plant" (and I forget what else),
but clicking on it with a knife would give you "pick bonding plant",
"cut bonding plant", "dig up bonding plant" , and "throw knife at
bonding plant".
Oh, and also clicking an object in hand on the background where there
was no hot spot would bring up its own interaction menu, including
"drop", "throw", "examine", and any individual verbs. That was one of
the biggest things I missed about ZN: being able to use items in hand
without a second object to use them on.
Joe
okbl...@usa.net
In article <6lkeai$qt$1...@nnrp1.dejanews.com>,
> opting for a different balance of power; both methods have advantages, and
> disadvantages, and I sincerely doubt that one is proveably better than the
> other.
>
*anything*?
[ok]
Andrew Plotkin
okbl...@usa.net wrote:
> In article <6lkeai$qt$1...@nnrp1.dejanews.com>,
> L. Ross Raszewski <rras...@hotmail.com> wrote:
> >
> > What I'm suggesting _isn't_ the bastardization of an ideal interface -- it's
> > opting for a different balance of power; both methods have advantages, and
> > disadvantages, and I sincerely doubt that one is proveably better than the
> > other.
> >
> Heh. Haven't we already proven that *nothing* is proveably better than
> *anything*?
Nothing is better than anything.
A ham sandwich is better than nothing.
Therefore, a ham sandwich is better than anything.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Bill
L. Ross Raszewski wrote:
>---The Parser's Credo---
>
>I will provide you with an immersive world.
>I will allow you to go anywhere, do anything you could in reality.
>I will accept any sentence, understand it, and do what you like.
>I will understand you.
>
>In return, you will restrict your actions to the scope of this game.
>You will form your instructions in the format I understand.
>You will use only the words this game provides.
>You will not attempt to press the boundaries of the game world
I don't agree with this. A clever design should:
1. Deals with instructions it doesn't understand in a manner that maintains
the illusion.
2. Deals with unknown words in a similar manner.
3. Limits the player to the boundaries of the game world via. resonable plot
devices. My favorite is having the adventure take place on some sort of
vehicle (aircraft, ship) or an island etc....
Bill
okbl...@usa.net
In article <erkyrathE...@netcom.com>,
erky...@netcom.com (Andrew Plotkin) wrote:
>
> Nothing is better than anything.
>
> A ham sandwich is better than nothing.
>
> Therefore, a ham sandwich is better than anything.
>
Works for me.
By the way, are any systems using GLIK yet? I'm intrigued but I don't really
grasp the applicability yet.
L. Ross Raszewski
I didn't say it was ideal. I said it was the way things are. In article
<o2Af1.15529$Kx3.13...@news.rdc1.sdca.home.com>,
"Bill" <bv...@inetworld.net> wrote:
>
> I don't agree with this. A clever design should:
>
> 1. Deals with instructions it doesn't understand in a manner that maintains
> the illusion.
> 2. Deals with unknown words in a similar manner.
> 3. Limits the player to the boundaries of the game world via. resonable plot
> devices. My favorite is having the adventure take place on some sort of
> vehicle (aircraft, ship) or an island etc....
>
> Bill
>
>
I didn't sya it was ideal. I said it was the way things are. A quick perusal
of the IF archive tells me that this is what we do, even if we shouldn't.
Can you tell me a way to handle unknown words in a reasonable manner?
I don't know the word "x" shatters the illusion for certain values of x
You can't see any x here. shatters the illusion for certain values of x.
and [You don't need to use the word 'x' to complete this game]. steps right in
through the tenuous veil we call mimesis, and reminds you that this is a
computer parser, not a real world.
I may have phrased it poorly, or flubbed the details, but my point is this:
we enter into an agreement with the parser, and it's an awfully demanding
agreement. The parser can't break it alone, not if it's bug free, this
agreement is coded into its very bytecode. But we can't always keep up our
end of the bargain.
I'm going to put my cards on the table, and draw _my_ line in the sand. I
would be willing to expect less from the parser, if the parser demanded less
of me. I am never going to get this veil of illusion that most call mimesis,
but I will call "total mimesis" from an adventure game. _I can't_ keep up my
end of the deal. My mimesis is ALWAYS going to break down.
So, for _me_, if the parser doesn't even try to provide me with the white stag
of "total mimesis", I'm not liable to be bothered. If the parser asks less of
_me_, I'll accept less from it. My mimesis doesn't "break" in this situation,
because we both keep up our ends of the bargain. Perhaps I don't get this
mystical, immersive, magical experience of total mimesis, but I get what I
bargained for.
To _me_, it's a lot better than being offered total mimesis, and living in
perpetual disappointment when it doesn't deliver.
That's the way I think about it. I'm probably alone, but I'd like to think
I'm not. I understand that there are other valid perspectives, but... for
everyone who makes such a big deal about the feeling of boundlessness, that
you can "go anwhere, do anything".... How long did it take for the walls of
that illusion to come crashing down? And how did you feel when it happened?
Bill
L. Ross Raszewski asks:
>Can you tell me a way to handle unknown words in a reasonable manner?
>I don't know the word "x" shatters the illusion for certain values of x
>You can't see any x here. shatters the illusion for certain values of x.
>and [You don't need to use the word 'x' to complete this game]. steps right
in
>through the tenuous veil we call mimesis, and reminds you that this is a
>computer parser, not a real world.
The best ideas I've heard on this are:
1. Conversations:
a. Artifical Stupidity ... have the NPC say something appropiate but not
relivant. I.E.
Player: So tell me about the armadillos?
NPC: You know, I'm a bit tired right now.
b. Elisa: Pick out the unknown stuff and throw it back at the player.
Player: So tell me about the armadillos?
NPC: Why, are you frightened by armadillos?
2. Commands: Two approaches:
a. Learning: Really difficult ... but possible. AND by the way
WILL SOMEONE Please TRY TO USE THE SOUNDEX OR OTHER SUCH SYSTEM TO DEAL WITH
MIS-SPELLED COMMANDS:
Player: Ingest the armadillo.
Computer: What do you mean by ingest?
Player: eat
Computer: I don't think the armadillo wants to be eaten.
b. Sillyness.
Player: Ingest the armadillo.
Computer: Wait, I think I've lost a bit there....
Maybe all commands should be in the form of a conversation? Actually my
preference is a graphical interface for object-object interactions and a
parser for conversations (and order NPC's to do stuff). Guess that makes me
a heretic on this NG.
>I may have phrased it poorly, or flubbed the details, but my point is this:
>we enter into an agreement with the parser, and it's an awfully demanding
>agreement. The parser can't break it alone, not if it's bug free, this
>agreement is coded into its very bytecode. But we can't always keep up our
>end of the bargain.
For years companies struggled to build hand held computers that could
recognize handwriting. The only one that suceeded (PalmPilot) FORCED the
user into a set of letter drawing styles to aid in the process. Sometimes
limits are good.
>I'm going to put my cards on the table, and draw _my_ line in the sand. I
>would be willing to expect less from the parser, if the parser demanded
less
>of me. I am never going to get this veil of illusion that most call
mimesis,
>but I will call "total mimesis" from an adventure game. _I can't_ keep up
my
>end of the deal. My mimesis is ALWAYS going to break down.
We're in agreement on this.
>So, for _me_, if the parser doesn't even try to provide me with the white
stag
>of "total mimesis", I'm not liable to be bothered. If the parser asks less
of
>_me_, I'll accept less from it. My mimesis doesn't "break" in this
situation,
>because we both keep up our ends of the bargain. Perhaps I don't get this
>mystical, immersive, magical experience of total mimesis, but I get what I
>bargained for.
>
>To _me_, it's a lot better than being offered total mimesis, and living in
>perpetual disappointment when it doesn't deliver.
I still think cleverness counts. Once you become accustomed to the parser
... you can get into the "this is real" sort of belief.
>That's the way I think about it. I'm probably alone, but I'd like to think
>I'm not. I understand that there are other valid perspectives, but... for
>everyone who makes such a big deal about the feeling of boundlessness, that
>you can "go anwhere, do anything".... How long did it take for the walls of
>that illusion to come crashing down? And how did you feel when it
happened?
It fell down when I couldn't use an object in a logical manner. A "you
can't do this" doesn't suffice.
The inability to achieve perfection is not an excuse for doing a bad job.
Bill
David Glasser
Andrew Plotkin <erky...@netcom.com> wrote:
> okbl...@usa.net wrote:
> > Heh. Haven't we already proven that *nothing* is proveably better than
> > *anything*?
>
> Nothing is better than anything.
>
> A ham sandwich is better than nothing.
>
> Therefore, a ham sandwich is better than anything.
Prove the Transitivity of betterness.
--David Glasser
gla...@NOSPAMuscom.com | dgla...@NOSPAMfcs.pvt.k12.pa.us
http://onramp.uscom.com/~glasser | http://www.geocities.com/SoHo/6028
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Interactive Fiction! MST3K! David Eddings! Macintosh!
Brad O`Donnell
L. Ross Raszewski wrote:
>
> ---The Parser's Credo---
[snipped]
> ---
> THe problem is that we put too much emphasis on the first part of this credo,
> and too little on the second.
>
> And the problem is not that parsers are failing their end of the bargain, but
> that we are _unable_ to meet our end.
>
> And if _we_ don't, mimesis is broken.
I agree with this wholeheartedly. I think players expect too much from
technology.
There is one thing missing from the proper contract between
player and game: a definition of what dialect of Adventurese the game speaks.
No matter how close some inputs come to plain English (or Spanish, or etc.)
Adventurese just isn't English. Old Sierra games used to come with a list
words, along the lines of "Here are the commands, and the forms of those
commands I accept." I don't know if the list was complete, but it sure
helped out when you got stuck guessing the verb.
More realistically, the game should at least (and quite a few games do)
tell where the commands deviate or extend from "Standard" Adventurese.
Since there is no standard, they don't do that, but at least they try,
as in spider and web, to tell where the game lingo deviates from the norm.
A good game can't be hurt, from my point of view, by this information.
> But the player is ALWAYS going to challenge the parser, so perhaps if we start
> expecting less from the interface, the interface will, in return, expect less
> from us, and we won't be disappointed as often.
Hooray! The return of the three-word parser:
>PUT LAMPSHADE HEAD.
Dust flies off of the lampshade as you gracefully prop it on your head.
****You are now ready to party in style****
--
Brad O'Donnell
"A story is a string of moments, held together by memory."
Andrew Plotkin
okbl...@usa.net wrote:
> In article <erkyrathE...@netcom.com>,
> erky...@netcom.com (Andrew Plotkin) wrote:
> >
> >
> > A ham sandwich is better than nothing.
> >
> > Therefore, a ham sandwich is better than anything.
>
Heh.
> By the way, are any systems using GLIK yet? I'm intrigued but I don't really
> grasp the applicability yet.
It's "Glk"; some people pronounce it "glick" but I pronounce it "gulk" or
"g@lk", if you read the @ as a schwa.
It's not an acronym.
Nothing is using it yet. I haven't done any work on it in the past few
weeks, because I've been moving and getting ready to start a new job. My
life is settling down now, (it better be, because my first day of work is
Monday), so I should be upgrading the source code soonish.
What's the applicability? Well, remember that list of VM features that
someone posted a few days ago? I've lost the post, but it was stuff like
more control over windows, more formatting options, better handling of
files and streams, provisions for graphics and sound, etc, etc.
That's what Glk does, except it *doesn't* include the whole virtual
machine. Basically, I started by trying to redesign the whole Z-machine
from the ground up -- but that's a large job. So I split the task into
what I felt were two natural sections. Glk is a solution to one of them.
(Consider the Z-machine's "CPU" and "I/O cards". Both could use some
improvement. I started with the I/O cards.)
Addressing a single problem is better than addressing two intertwined
problems at once. For one thing, if I proposed a replacement for the
entire Z-machine all at once, people would be shooting it down from *two*
sides. :-) And a problem with one side could sink the whole project.
Gunther Schmidl
>(Consider the Z-machine's "CPU" and "I/O cards". Both could use some
>improvement. I started with the I/O cards.)
Maybe we should try to get the current z-machine (+ additions) working
before thinking about refining and improving it? One word: BLORB.
Sorry, couldn't resist. I know people are out there working hard on
interpreters, but unfortunately that doesn't help my Work In Progress...
--
+------------------------+----------------------------------------------+
| Gunther Schmidl | "I couldn't help it. I can resist everything |
| Ferd.-Markl-Str. 39/16 | except temptation" -- Oscar Wilde |
| A-4040 LINZ +----------------------------------------------+
| Tel: 0732 25 28 57 | http://gschmidl.home.ml.org - new & improved |
+------------------------+---+------------------------------------------+
| sothoth (at) usa (dot) net | please remove the "xxx." before replying |
+----------------------------+------------------------------------------+
Matthew T. Russotto
In article <3583e...@alijku02.edvz.uni-linz.ac.at>,
Gunther Schmidl <sot...@xxx.usa.net> wrote:
}>(Consider the Z-machine's "CPU" and "I/O cards". Both could use some
}>improvement. I started with the I/O cards.)
}
}Maybe we should try to get the current z-machine (+ additions) working
}before thinking about refining and improving it? One word: BLORB.
There's several 0.2-Standard working Z-machine interpreters out there,
AFAIK. (Yes, my own is technically "Beta", but only because I haven't
changed the version and re-uploaded. I do not intend to make any
changes to it). The main changes in the 1.0 machine are Unicode and
nesting of stream 3, and I think I'd rather see a new machine than
implement them.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Andrew Plotkin
Gunther Schmidl (sot...@xxx.usa.net) wrote:
> >(Consider the Z-machine's "CPU" and "I/O cards". Both could use some
> >improvement. I started with the I/O cards.)
>
> Maybe we should try to get the current z-machine (+ additions) working
> before thinking about refining and improving it? One word: BLORB.
I wrote Blorb, and when I was finished, I said to myself, "This V6 mess
is hopeless. I'd better pitch it and start over."
This was a significant factor in the design of Glk. Really.
No, I'm not personally declaring V6 dead. I don't have the authority, no
matter what people joke about me. But I've decided that my own effort is
better spent on Glk than on helping make V6 widely usable.
Gunther Schmidl
>I wrote Blorb, and when I was finished, I said to myself, "This V6 mess
>is hopeless. I'd better pitch it and start over."
>
>This was a significant factor in the design of Glk. Really.
>
>No, I'm not personally declaring V6 dead. I don't have the authority, no
>matter what people joke about me. But I've decided that my own effort is
>better spent on Glk than on helping make V6 widely usable.
So (excuse me for asking, but I think I just don't understand the Glk
proposal)...
...is Glk going to support graphics, multiple windows &c just as the V6
"standard" does, but more widely portable and easier to program from within
Inform (which means I can trash all the V6 stuff I've written so far)?
...or what? Argh! I just don't get it!
Andrew Plotkin
Gunther Schmidl (sot...@xxx.usa.net) wrote:
> >I wrote Blorb, and when I was finished, I said to myself, "This V6 mess
> >is hopeless. I'd better pitch it and start over."
> >
> >This was a significant factor in the design of Glk. Really.
> So (excuse me for asking, but I think I just don't understand the Glk
> proposal)...
No problem -- I think my biggest problem is lack of publicity. :)
> ...is Glk going to support graphics, multiple windows &c just as the V6
> "standard" does, but more widely portable and easier to program from within
> Inform (which means I can trash all the V6 stuff I've written so far)?
It already supports multiple windows. It will support graphics, sound,
animation, network connections, and anything else we can define a
good API for and implement.
Yes, the aim is to do it as portably as possible. For example: the
line-breaking interrupts in V6 are a pain because they bite into the
text-display code. That is, an existing styled-text widget (like EditText
or the Max* engine) has to have surgery to accomodate the V6 interrupts.
It also makes assumptions about the display that annoy me. (Fixed window
characteristics -- the player can't change window size or display font in
mid-session.) Therefore (again, this is an example) the line-breaking
system is a V6 feature that will not show up in Glk.
Similarly, the image scaling system in Blorb+V6 is pretty horrific. It
exists only because people wanted to add scaled images without adding a
new V6 opcode. Glk will have something more sensible. (And note that it's
easy to add a new Glk "opcode" without breaking old interpreters *or* old
games.)
Now, it's not clear whether this will really replace V6, or become an
alternate output system available to Inform developers. To really support
Glk, we'll need a new VM.
(Footnote 1: It would be possible to extend the Z-machine to support Glk
natively. Basically you'd trash all the existing output opcodes, and add
a single Glk-multiplexer opcode. However, since Glk uses 32-bit
variables, you'd really want to extend the machine to be 32-bit as well.
And at that point you really have created a new VM; you could call it
"Z10" but I think you'd just be trapping yourself in an old-mold mindset
without any of the advantages.)
I think it's important for the next VM -- or one of the next wave of VMs
-- to be supported by Inform; that is, there should be an Inform-language
compiler that compiles to it. I have heard rumors that Graham thinks this
as well. However, you'll have to ask him about that.
Obviously, if there *is* a new VM that Inform compiles to, my big agenda
(agendum?) is for that VM to use Glk natively as its I/O system.
Does that answer your question? I don't know what authors *will* do; I'm
still working on what they will be *able* to do, at least through one
technology.
Damien Neil
On Mon, 15 Jun 1998 15:11:07 GMT, Andrew Plotkin <erky...@netcom.com> wrote:
>Yes, the aim is to do it as portably as possible. For example: the
>line-breaking interrupts in V6 are a pain because they bite into the
>text-display code. That is, an existing styled-text widget (like EditText
>or the Max* engine) has to have surgery to accomodate the V6 interrupts.
This reminds me of something that I wish Glk supported. Unfortunately,
I understand why it doesn't support it, and why it probably never will,
so I can't actually request it, but I may as well mention it and get it
off my chest. :>
I'd like to be able to output a block of text with a given prefix. For
example, the text in your post as quoted by my newsreader has a prefix
of ">". Now, you can't simply print each line with the prefix at the
front, because this breaks when the window is resized, or the font is
changed. So, ideally, the output interface could support it.
I suspect this breaks the "easily implementable in a generic text
widget" rule of Glk design, though. Ah, well.
My reason for wanting this is that Glk looks like it could become a
very nice UI mechanism for a program I work on. (A client for a simple
chat system.) Messages are generally formatted like this:
-> From damien, to computer:
- Glk is nifty!
The send body needs to be prefixed with " - ".
Anyway, none of this has anything to do with interactive fiction. :>
>Now, it's not clear whether this will really replace V6, or become an
>alternate output system available to Inform developers. To really support
>Glk, we'll need a new VM.
So, when can we expect the Zarf-machine? :>
- Damien