TADS as a MUD language

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

I'm a long term player and programmer on LambdaMOO [1], and also and
avid IF player. For a long time I have been frustrated with the
builtin parser on Lambda. In comparison to standard IF languages like
TADS and Inform, it is very primitive. It only allows fairly basic
commands of the form "verb noun preposition noun", and has very poor
ability to handle disambiguation etc.

I've just been reading the TADS manual (2.55) and I'm impressed by the
cleverness of the parser. It allows a lot more flexibility in commands
without overly complex syntax (at least for the simple cases). I would
love to see a MUD with this kind of parser.

Has anyone considered writing a MUD which uses TADS as it's internal
language? Given that TADS already has support for multiple actors, it
seems to me that it shouldn't be too hard to do so. The main
assumption that would need to be changed is that in TADS all messages
are directed at the player. Whereas in a MUD there are many players
and commands would have to be able to direct different messages to
different users.

Now I admit I haven't written anything in TADS yet, so I make be
speaking out of my hat, but this doesn't seem like too giant a leap to
me. Has anyone given it thought? What do you see as the problems?

Malcolm

[1] http://www.moo.mud.org/

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

There's a huge problem in that things like TADS are turn-based, whereas
any multiplayer game has to run in realtime. Plus see Zarf's comments
about breaking stuff. What you *could* do is yank some of the parsing
code and implant it into one of the more customizable codebases; LP is
way better than the MUCK, MUSH, ROM, MOO, etc. stuff for this because
it is done with user-modifiable dynamically compiled code.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

All that I was saying was that retrofitting this into TADS, or a zcode
interpreter for that matter, would seem to be more work than it was
worth if you just wanted the parser code. Anything designed for
single-player, turn-based interactive fiction is going to have a whole
lot of baggage that will be a liability for a chat- or
hack-and-slash-based MUD. It would be more efficient, at least in my
opinion, to take an existing MUD codebase, delete the parser, and
replace it with your own, perhaps transcribing the parsing code from
TADS or Inform, than to go the other way around.

Of course, this goes both ways -- since MUDs are realtime, they are
better suited to having a much simpler command set and unsophisticated
parsers; if you're in the middle of a real-time fight with a demon, you
want to type something like "mm" rather than "Cast the 'magic missile'
spell upon the foul Demon, in the name of Saint Gregory!" IF parsers
are designed to contribute to the fiction and helps to remove
"guess-the-verb" puzzles; MUD parsers are designed to compress
unnecessary typing to a minimum.

At the risk of going off on a tangent, the turn-based/real-time
dichotomy is probably one of the most overlooked but important aspects
of gameplay. I remember seeing a multiplayer version of rogue (which is
a quintessential multiplayer game) which attempted to create an
illusion of turn-based play whenever feasible by slowing
computer-controlled events to match the speed of the fastest player in
a given area. So if you are alone somewhere on the map, it plays like
regular turn-based rogue; if there's another player near you, you have
to at least match his speed. This sounded like a good idea until
someone came past holding down an arrow key, causing him to fly past
and giving the monster I was fighting an enormous number of turns to
which I couldn't possibly respond. It was just a level 1 monster, of
course, but it managed to get in about 25 hits on me before I even
figured out what had happened. So it's decidedly nontrivial to resolve
something like this.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Here, Malcolm Ryan <malcolmr.google@cse.unsw.edu.au> wrote:
>
> Has anyone considered writing a MUD which uses TADS as it's internal
> language?

I don't know TADS but I've thought about it for Inform, and my feeling
is that these languages are highly tuned for single-author games. They
make it as easy as possible to customize the grammar for particular
scenarios. Not just adding new verbs, but resolving ambiguities in a
way suited to a particular set of objects and actions.

The problem for a MUD is that it's patchwork -- there's an underlying
assumption that every area is discrete, with its own set of possible
actions. So there's no way to adjust the grammar globally. If there
was, every new MUD builder would almost certainly break existing areas
of the game.

(IF languages have the same problem, but it's manageable because (a)
one person is creating every area, and (b) at some point the game is
finished, so new creation stops.)

(I know, IF is never *really* finished...)

Again, I'm not just talking about adding new verbs. An IF author does
a lot of redesigning of existing verbs. (The Inform library has
"think" as a single-word verb, but some games want "think about ...".
Furthermore, those games want the input "think" to return a
disambiguation query, not a fixed response.)

The same issue exists with object names. An IF author will naturally
-- even unconsciously -- ensure that if his game has two knives, one
of them is "the rusty knife" and one is "the nasty knife". Or
whatever. But if two people are working on a MUD, nothing prevents
them from both creating a "nasty knife", and then you have potential
trouble.

I'm not saying this is a fruitless idea, but you *are* going to have
to dig down to the core assumptions and do some redesign.

(Or limit yourself to fixed multiplayer scenarios created by a single
author. In that case, none of the above applies.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Here, daniel_mcl@hotmail.com <daniel_mcl@hotmail.com> wrote:
> There's a huge problem in that things like TADS are turn-based, whereas
> any multiplayer game has to run in realtime.

That's not hard to deal with: you serialize inputs. Deal with them,
one at a time, in the order that they arrive. The MUDs that I
know of already do this.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Here, Andrew Plotkin <erkyrath@eblong.com> wrote:
> Here, daniel_mcl@hotmail.com <daniel_mcl@hotmail.com> wrote:
> > There's a huge problem in that things like TADS are turn-based, whereas
> > any multiplayer game has to run in realtime.
>
> That's not hard to deal with: you serialize inputs. Deal with them,
> one at a time, in the order that they arrive. The MUDs that I
> know of already do this.

To expand on this:

There's a higher-level design problem, which may be what you were
thinking of: You can't do the kind of puzzle, common in single-player
IF, where you have N turns to defuse the bomb before it goes off.
Since all the players are sending commands asyncly, a fast typer can
drown you out -- N turns may go by in the engine before you even have
a chance to send one command.

The first-cut answer is "don't design puzzles like that in multiplayer
games". The longer answer has not, I think, been explored yet.

In any case, the problem has nothing to do with the parser mechanism.
It's just as applicable to the old TinyMUD coding language as it would
be to MUD-TADS.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Andrew Plotkin <erkyrath@eblong.com> wrote in message news:<cm8476$is4$1@reader1.panix.com>...
> Here, Malcolm Ryan <malcolmr.google@cse.unsw.edu.au> wrote:
> >
> > Has anyone considered writing a MUD which uses TADS as it's internal
> > language?
>
> The problem for a MUD is that it's patchwork -- there's an underlying
> assumption that every area is discrete, with its own set of possible
> actions. So there's no way to adjust the grammar globally. If there
> was, every new MUD builder would almost certainly break existing areas
> of the game.

Sure, but that problem exists already. If anything, a better parser
could allieviate it. For example, currently on LambdaMOO, if you have
two apparently identical daggers in the same room, there is NO way to
get one of them, without resorting to peeking "behind the scenes" to
find out their object numbers. A better parser would allow you to say
"get a dagger" and pick up either one.

Malcolm

PS: Oh, I can't hide it any longer! Imagine: _The_ Andrew Plotkin,
replying to humble little me! <swoon> I'll never was this monitor
again! 😉

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

In article <1099414192.994112.320210@f14g2000cwb.googlegroups.com>,
"daniel_mcl@hotmail.com" <daniel_mcl@hotmail.com> wrote:

> There's a huge problem in that things like TADS are turn-based, whereas
> any multiplayer game has to run in realtime.

Well, he could try TADS 3. Since T3 lets you replace the main loop and
supposedly allows fuses that fire even if the user isn't doing anything
right now, it would probably count as not turn-based already.

The biggest problem left then would be to get the network I/O working.

As to the problem of objects with the same name: That could probably be
handled by the compiler, or by a preprocessor applied to the files
before compilation. It would simply complain if anyone tried to check in
new content that has a name that is the same as another existing object.

It's definitely solvable. The problem being: Who is going to implement
the needed changes? Maybe MJR would be interested in that, or maybe he's
fine with what TADS does right now, then you'd have to find someone
willing to find out about the guts of TADS to implement it.

Cheers,
-- Uli
http://www.zathras.de

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

"daniel_mcl@hotmail.com" <daniel_mcl@hotmail.com> wrote in message news:<1099430443.754579.54160@z14g2000cwz.googlegroups.com>...
> Of course, this goes both ways -- since MUDs are realtime, they are
> better suited to having a much simpler command set and unsophisticated
> parsers; if you're in the middle of a real-time fight with a demon, you
> want to type something like "mm" rather than "Cast the 'magic missile'
> spell upon the foul Demon, in the name of Saint Gregory!" IF parsers
> are designed to contribute to the fiction and helps to remove
> "guess-the-verb" puzzles; MUD parsers are designed to compress
> unnecessary typing to a minimum.

Well, yes and no. Not all muds are combat muds. On social muds there
is some value placed on the quality of the "fiction" -- at least on
the MUDs where I build! And even if it isn't a widespread priority at
the moment, doesn't mean that we shouldn't explore the possibility. As
Zarf says, some interesting issues arise when we start trying to build
multi-player IF-stories (or, at least, when we try to do it well). I'd
like to explore these things.

But the point about taking the parser to the MUD rather than vice
versa is well made. I was just thinking that a lot more work has been
done on quality parsers here in the IF community, rather than there in
the MUD community. I'd be a fool not to take advantage of your wisdom
and experience.

The biggest problem is that I'd have to start a new MUD, and
attracting an audience is always difficult.

While I'm here, can I make a suggestion for IF writers? Coming from a
MUD background, I am used to having certain social verbs like "wave",
"laugh", "smile" etc available to me. Playing IF, I sometimes find
myself trying to use them. I don't expect them to DO anything, in game
terms, but it would add to the experience, for me at least, if I could
type "smile" at the appropriate point and see the message "You
smile.". Just a thought.

Malcolm

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

>Andrew Plotkin erkyrath@eblong.com wrote:
>But if two people are working on a MUD, nothing prevents
>them from both creating a "nasty knife", and then you have
>potential trouble.

The Skotos parser uses numbering, so you can refer to
the 'first knife' or the 'second knife' or 'fifty-ninth knife'
and so on.

This also splits across classes, so you might refer
to the 'fifth donut' or the 'tenth food' and get the same
thing, because the foods are combined across the
room.

Jason Dyer
jdyer41@aol.com

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Does that mean you're interested in working on something like this?

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Here, daniel_mcl@hotmail.com <daniel_mcl@hotmail.com> wrote:
> Does that mean you're interested in working on something like this?

Who are you speaking to? (Quoting in Usenet messages is preferred to
avoid this kind of ambiguity.)

I am not personally interested in working on importing IF parsers into
MUDs. I do intend to eventually add networking capabilities to Inform,
which would allow multi-player, but single-author, games. I'm
confident that current IF parsers can handle that.

(BTW, several people commented on my point earlier about objects with
conflicting (identical) names. That was just one example. Conflicting
verb forms are a bigger problem.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

> Who are you speaking to? (Quoting in Usenet messages is preferred to
> avoid this kind of ambiguity.)

Sorry, the google groups interface seems to frown upon quoting and
instead rely on heirarchy; it's easy to forget that there are other
kinds of newsgroup readers out there.

I was replying to Max; I was saying that I'm interested in working on
creating multiplayer IF, in the sense of a pre-written story (perhaps
"single-author" isn't the best term, since even the zcode stuff that's
popular today can be collaborative) in which a group of n players, for
some fixed n, play the different characters in the game; i.e. one
player can play Watson and another can play Holmes.

Since it appears a bunch of people are interested in this, it'd be nice
to get everyone together here and now and agree on one set of
libraries, etc. Setting up Inform to handle multiplayer is going to
take some serious infrastructure reinforcement -- there's a bunch of
stuff in there that expects to be seeing turn numbers ticking by, and
all of this is going to have to be tweaked. This isn't necessarily
*challenging* per se, but it's better not to have 17 people each
writing their own library with its own particular quirks and create a
huge mess of misdocumentation and confusion.

It'd also be nice to have an IFComp equivalent for the multiplayer
games, though I'm getting ahead of myself a little bit here.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

> Who are you speaking to? (Quoting in Usenet messages is preferred to
> avoid this kind of ambiguity.)

Sorry; I'm using the google beta reader which depends entirely on
heirarchies and doesn't do quoting (I had to manually put in those >
signs up there). It's easy to forget that there are other readers out
there.

I was replying to Max, and by extension to anyone interested in
developing multiplayer IF. Personally, I've sworn off of MUDs because
they're lacking in the elements I like most in story-based IF. Maybe
we should start a new thread to discuss this; it'd be nice to quickly
agree on the development platform, virtual machine format, library
routines, and the like and maybe to get the infrastructure in place for
a multiplayer analog to the IFComp.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

daniel_mcl@hotmail.com wrote:


> Sorry; I'm using the google beta reader which depends entirely on
> heirarchies and doesn't do quoting (I had to manually put in those >
> signs up there).

Yes, it does. To get quoting, you have to use the Show Options link on
the message and click on Reply from there.




Brian