English Language Parsing

0 views
Skip to first unread message

William M. McCarroll

unread,
Feb 17, 1997, 3:00:00 AM2/17/97
to

Before I say anything, I just want to state that the problem that
I am wrestling with is for a MUD, and allthough discussion of MUD
related material isn't looked upon nicely here, I feel it has more
relevance to interactice fiction than traditional muds.

With MUDS it is very difficult to create a "storyline" as the
mud has no beginning or end, it exists to allow interaction. And
"puzzles", once solved are spread amongst the other players, and
rendered basically useless. I want to create a more hybrid system
that allows plots and subplots to form from seeming chaos, Hack &
Slash gets pretty boring if you ask me ;).

The first step to make the mud more enjoyable to use is to get rid
of the current parsing system. when we implemented it at first it
was something that just got the job done. Now I want to implement an
english language parser. I was very impressed with the system that
infocom used. It amazed me what they could do on a C64 with 64k of
ram. Is there any documentation of this on the internet, or books that
I could buy that would help me with this subject. I am so tired of the
basic 3 word command system: verb noun target.

Also, if anyone has any Ideas to spice up a mud system, I would
appreciate it. Anything to enhance roleplaying and allow players to
create their WON storylines would be excellent!

thanks for your time!


--
William M. McCarroll | U.S. Diamond Exchange
Systems Administrator | (702) 368-0205
neos...@mail.usdiamond.com | http://www.usdiamond.com/
----------[Please, Don't eat the Linoleum.]------------

Stephen Granade

unread,
Feb 17, 1997, 3:00:00 AM2/17/97
to

On Mon, 17 Feb 1997, William M. McCarroll wrote:
> The first step to make the mud more enjoyable to use is to get rid
> of the current parsing system. when we implemented it at first it
> was something that just got the job done. Now I want to implement an
> english language parser. I was very impressed with the system that
> infocom used. It amazed me what they could do on a C64 with 64k of
> ram. Is there any documentation of this on the internet, or books that
> I could buy that would help me with this subject. I am so tired of the
> basic 3 word command system: verb noun target.

Graham Nelson discusses the design of a parser in either the Inform
Designer's Manual or the Technical Manual. I cannot for the life of me
remember which right now, so you might want to look at both. They are
available from ftp.gmd.de:

ftp://ftp.gmd.de/if-archive/infocom/compilers/inform6/manuals/

The technical manual is technical_manual.txt; the designer's manual is
available in a variety of flavors, all listed as designers_manual.* with
only the extension differing.

Hope this helps.

Stephen

--
Stephen Granade | "It takes character to withstand the
sgra...@phy.duke.edu | rigors of indolence."
Duke University, Physics Dept | -- from _The Madness of King George_


they got purple; purple's a fruit

unread,
Feb 19, 1997, 3:00:00 AM2/19/97
to

And behold, William M. McCarroll <neos...@usdiamond.com> did spake, speaking:

> Before I say anything, I just want to state that the problem that
> I am wrestling with is for a MUD, and allthough discussion of MUD
> related material isn't looked upon nicely here, I feel it has more
> relevance to interactice fiction than traditional muds.
>
> With MUDS it is very difficult to create a "storyline" as the
> mud has no beginning or end, it exists to allow interaction. And
> "puzzles", once solved are spread amongst the other players, and
> rendered basically useless. I want to create a more hybrid system
> that allows plots and subplots to form from seeming chaos, Hack &
> Slash gets pretty boring if you ask me ;).

MUD is a terrible system to create puzzles with. You'd be far better off
using a MUSH or MUCK or one of those hybrids, hell, even a MOO. They exist
more for the programming than the interaction, (well, perhaps, programming
over interaction, but both are 'equal') and can be programmed as such to
handle complicated sentences - however even then it's a bit of a code
kludge. It's also hard, object-wise, to handle multiple puzzle objects to
be held and used by many different players - cloned objects for every player
would work, but are hell on system resources, while a single object must be
'returned' to its spot once a player is finished with it, and with many
objects, restricts gameplay to one person at a time, in which case you'd be
better off just writing for non-multiplayer use.

I suggest you go out and look at some MUSHes or MUCKs, check their
programming out, and consider implementing one of them. For all their
faults, they're still lightyears ahead of MUDs when it comes to
problem-solving and puzzle implementing.

Good luck, eh.


--
spa...@error.net, chief engineer (toot toot!) Spatula Labs, error.net/~spatula

"Pez is cheap; smiles are priceless." - C. L. McCoy
mstie#43790


Andrew Plotkin

unread,
Feb 19, 1997, 3:00:00 AM2/19/97
to

they got purple; purple's a fruit (spa...@underground.error.net) wrote:
> And behold, William M. McCarroll <neos...@usdiamond.com> did spake, speaking:
> > With MUDS it is very difficult to create a "storyline" as the
> > mud has no beginning or end, it exists to allow interaction. And
> > "puzzles", once solved are spread amongst the other players, and
> > rendered basically useless. I want to create a more hybrid system
> > that allows plots and subplots to form from seeming chaos, Hack &
> > Slash gets pretty boring if you ask me ;).

> MUD is a terrible system to create puzzles with. You'd be far better off
> using a MUSH or MUCK or one of those hybrids, hell, even a MOO. They exist
> more for the programming than the interaction, (well, perhaps, programming
> over interaction, but both are 'equal') and can be programmed as such to
> handle complicated sentences - however even then it's a bit of a code
> kludge.

It's not the programming difficulty we're talking about, but the whole
MUD paradigm.

(Huh huh huh -- "paradigm". Huh huh.)

TinyMUD was certainly a pain to program for, since it didn't have any
programming language except for boolean combinations of objects, used to
lock doors and object-picking-up. (In other words, you could mark a door
as "can't go through unless you are holding ((X or Y) and Z and W)". And
you could mark an object as "can't pick up unless you are holding..."
etc. That was about it as far as programming constructs, although I am
leaving out a few things less useful to puzzle construction.)

> It's also hard, object-wise, to handle multiple puzzle objects to
> be held and used by many different players - cloned objects for every player
> would work, but are hell on system resources, while a single object must be
> 'returned' to its spot once a player is finished with it, and with many
> objects, restricts gameplay to one person at a time, in which case you'd be
> better off just writing for non-multiplayer use.

But this is exactly the problem, and it applies equally to all MUDs that
I've seen. You can "lock" a quest/puzzle once a player is inside it; that
means you're just writing a single-player scenario. You can clone the
scenario and all contents for each player that enters; ditto. Or you can
allow multiple people inside, with the near-certainty that some will drop
out early, or come in late, and break your scenario.

--Z

--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

they got purple; purple's a fruit

unread,
Feb 20, 1997, 3:00:00 AM2/20/97
to

And behold, Andrew Plotkin <erky...@netcom.com> did spake, speaking:

> they got purple; purple's a fruit (spa...@underground.error.net) wrote:
> > And behold, William M. McCarroll <neos...@usdiamond.com> did spake, speaking
>
> It's not the programming difficulty we're talking about, but the whole
> MUD paradigm.
>
> (Huh huh huh -- "paradigm". Huh huh.)

A paradigm, a paradigm, a most ingenious paradigm...

>
> TinyMUD was certainly a pain to program for, since it didn't have any
> programming language except for boolean combinations of objects, used to
> lock doors and object-picking-up. (In other words, you could mark a door
> as "can't go through unless you are holding ((X or Y) and Z and W)". And
> you could mark an object as "can't pick up unless you are holding..."
> etc. That was about it as far as programming constructs, although I am
> leaving out a few things less useful to puzzle construction.)

MUD goals are usually the same - either to get to some place or to get a
piece of equipment (or level or get a date or ... ok, now I'm getting
ahead of myself.)

>
> > It's also hard, object-wise, to handle multiple puzzle objects to
> > be held and used by many different players - cloned objects for every player
> > would work, but are hell on system resources, while a single object must be
> > 'returned' to its spot once a player is finished with it, and with many
> > objects, restricts gameplay to one person at a time, in which case you'd be
> > better off just writing for non-multiplayer use.
>
> But this is exactly the problem, and it applies equally to all MUDs that
> I've seen. You can "lock" a quest/puzzle once a player is inside it; that
> means you're just writing a single-player scenario. You can clone the
> scenario and all contents for each player that enters; ditto. Or you can
> allow multiple people inside, with the near-certainty that some will drop
> out early, or come in late, and break your scenario.

And unfortunately should someone lose the connection either the MUD must
reset the game automatically, or it's up to someone else to reset it. I
once saw a game on a MUSE that required four people to play and complete
the game (based on the Chronicles of Narnia, each person had to sit in a
separate throne to trigger the endgame) but of course, should one person
leave the area unexpectedly, the other three were SOL.

*shrug*

The perfect multiplayer IF environment hasn't been created yet, IMHO.

--
derSpatchel resides at http://error.net/~spatula, among other places.

Aborting posts stops a beating dead horse. Don't do it.
mstie#43790


Reply all
Reply to author
Forward
0 new messages