[MUD-Dev] "short" Introductory Message (fwd)

[Caliban Tiresias Darklock]

On Fri, 6 Jun 1997 19:42:50 PST8PDT, Martin Keegan <martin at cam.sri.com>
wrote:

>I've had a look at many mud languages, and didn't like any. 'Mud languages' 
>sums these up very well. Muds, as far as I'm concerned, are "virtual worlds", 
>and the languages used to describe them tend to be modelled on general 
>programming languages rather than reflecting virtual worlds in their design.  

This is something I've been trying to say for a while, but I keep being
told that all I'm doing is waging a codebase war. 

Basically, the internal command parser and programming language of a MUD
tends to assume a lot of familiarity with the internal workings of the
MUD server. There are exceptions, but those exceptions in general tend
to give you nothing to build on; you have to start from a clean slate,
which is often a good way to build your MUD if you have a very odd or
complex idea which departs greatly from the usual sort of design.
However, most of the changes people want to make are incremental... they
want to add a few new spells, or a couple classes or races, or something
like that. The general sort of thing I use to consider a MUD language
'successful' is a list something like this.

	Object and room creation are quick, simple, and easy.
	Created objects and rooms are instantly viable.
	Created objects and rooms are automatically saved.
	Command syntax is sensible, intuitive, and documented.

Obviously I could go into much greater detail on this, but there is one
very simple benchmark. If I can sit down and teach someone enough of the
command structure to play the game effectively within an hour, enough of
the building interface to build coherent areas within a day, and enough
of the programming language to build an entirely new object effectively
within a week -- then the language is successful. Ideally, in double
these time frames, a dedicated player should be able to learn all of
this on his own through documentation and help. 

The problem I have in trying to define the language structure the way it
ought to be defined, as always, is the general problem of what is too
much detail and what is too much generality. 

>LPC, the best known "mud language", I found to be way too general: you can 
>write webservers in it; it's not a world description language but a general
>programming language with Mud-flavoured knobs on. 

I haven't spent a lot of time with LPC, which keeps being thrown in my
face. What I have seen of it has struck me as being the sort of thing
that is just as flexible, difficult, and danger-ridden as hardcode...
which makes me wonder exactly what the advantage of LPC over hardcode is
in the first place. It almost seems to be like writing under a C
interpreter using an additional set of libraries.

>E works as a series of definitions of entities within a model world. 
>Entities can inherit features of other entities. That's basically all
>there is to it, and such concepts will doubtless be familiar to most
>people on this list. The interpreter enforces very little in the way of
>type or sanity checking. Not only are objects, doors, monsters and rooms
>described in E, but the grammar and syntax of the language used to access
>the mud (the parser, effectively) are also defined. 

I was thinking about doing something like this myself... a sort of
'micro-server', which handles absolutely nothing except reading a
configuration file and accepting connections. We got awfully bogged down
in implementation details, though, when my main concern was how to
implement the configuration interface rather than how to structure the
code internals.

>In text-based muds, we use languages to communicate between human players
>and the computer-controlled game. The "suspension of disbelief" upon which
>immersive experiences (and other fiction, whether interactive or
>otherwise) like mudding depends can be impaired if the user's attention is
>distracted from the content by the interface. 

Yes! Exactly! I've been trying to say this, too... I think the major
problems I've had in getting these points across is the contrast of
people who are trying to suspend disbelief and people who aren't. When I
offer both sides of the coin, people seem to infer that whichever side I
am personally on is the side I'm trying to advance, which in turn
implies that I'm beating up on the other side.

>Similarly, the parser must attempt to accept as broad a subset of natural
>English (or whatever language the mud is in) as possible; having to
>wrestle with a commandline parser is not conducive to enjoyment of a mud. 

I'm not entirely in agreement with this. I think there's a point of
diminishing returns, where you get caught up in the 'time flies like an
arrow, fruit flies like a banana' problems and neglect other more useful
concerns like making the server itself more efficient. I don't think
natural language processing necessarily adds a lot to a MUD; I think
instead the proper selection of a subset of the language which can
express most (although not absolutely ALL) of the situations that arise
is more than adequate, and requires much less effort to implement than a
true natural language processor.

-+[caliban at darklock.com]+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 I am here to grind your eyes harder into the miasmic bile of life; to 
 show you the truth and the beauty in the whisper of steel on silk and 
 the crimson scent of blood as it rises to meet the caress of a blade. 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+[http://www.darklock.com/]+-