Path: utzoo!utgpu!watserv1!watcgl!sfwhite
From: sfwhite@watcgl.waterloo.edu (Stephen White)
Newsgroups: alt.mud,news.groups
Subject: UltiMUD (was Re: CALL FOR DISCUSSION: rec.games.mud)
Message-ID: <13274@watcgl.waterloo.edu>
Date: 6 Feb 90 20:23:16 GMT
References: <9510@medusa.cs.purdue.edu> <4107@jarthur.Claremont.EDU> <1457@husc6.harvard.edu> <637@m1.cs.man.ac.uk>
Reply-To: sfwhite@watcgl.waterloo.edu (Stephen "Ghondahrl" White)
Organization: U. of Waterloo, Ontario
Lines: 94

In article <637@m1.cs.man.ac.uk> pjc@r1.UUCP (Peter Crowther (CAG ra)) writes:

} wizard on UglyMUG (derived from TinyMUD 1.4.1 Beta - I've added deletion
} of objects, newlines in descriptions. I'm about to add containers and a
} *very* general compound command mechanism.)

I'm interested in your deletion algorithm.  Does it allow for deletion
of players?

I've decided to cut short my work on the next generation of TinyMUD's
(ie., with imbedded programming language, etc. as Asp & I had discussed).
If I don't I'll be in danger of flunking out:  not a good scene.

What I'll do instead is toss my ideas out for the MidGaard folks.

What Asp mentioned about a simplified programming language (with
if/then/else constructs and bounded loops) helped me to come up with
some ideas for an idealized MUD.

What I've been trying to come up with is a very simple language which
would allow all commands (including the existing get/drop, etc.) to
be expressed in a simple form, using a very small set of built-in
functions.  Each object/room/player would then "link" to a set of
actions by default.  For example, "get" might be expressed as

get $1
if (locof($1) != locof($player)) then
    tellplayer("I don't see that here.");
else
    move($1, $player)

This action would be written only once, as the default "get" for an 
object.  An object would "link" to this program, and the player
could then over-ride the default by writing their own program
and linking to it instead.

locof(thing), move(thing, dest), tellplayer(message) and
tellothers(message) might be the only required functions--any ideas
here?  Perhaps the ability of a program to re-@desc or re-@name
an object should be allowed, or to compare strings (this would
cut down on object-swaps and string-duplication)

Note that I'm using a C-like syntax ... it's just what I know best,
perhaps something LISP-like would be better.  Also, the concept
of "key" has been removed; it has to be added in by the player.

In fact, the only required fields might be: name, description, owner,
flags, location, contents, and a new one, "programs".  Asp suggested
that all types of objects would be derived from a superclass which
defines the functions which may be performed on it.

This "program" might be stored as an object, like everything else,
except that it could be "linked to" by any player.

The only problem I see with this scenario is access.  If you
link to a program created by another player, the program will
now be moving around things created by the first player, not
the creator of the program.  Perhaps programs should have a
"LINK_OK"-type flag, to indicate that others may use them.
The "programmer" would be responsible for not making publicly
accessible programs which did things he didn't want them to (ie.,
move around important objects).

Crude containers might be implemented as follows:

put $1 in $2
if locof($1 != player)
    tellplayer("You don't have that!")
else 
    move($1, $2)
    tellplayer("You put $1 in $2.")

(The existing "contents" field could be used, but the "get" action
would have to be modified to check the contents of each object in the
player's inventory and room objects' contents for items to extract,
if such functionality was desired).

This program would only be linked to by whichever objects were
to be containers.

I should mention that although I was initially distrustful of
the idea of programs in MUD's (being wary of bad programs crashing
the entire MUD), I have since been convinced that it is the only way
to go.  TinyMUCK is a clever way to tack on some new features
into the structure of TinyMUD, but it doesn't allow the full
flexibility of a programming language.  (And, as anyone who
has used it will tell you, TinyMUCK is definitely lacking in
the ease-of-use area.)

-- 
        ___         Stephen White       standard_disclaimer()
 ______/__	    sfwhite@watcgl.waterloo.edu  
<___   |  \  /\  /  "If the world was an orange, it would be like,
 ___>  |   \/  \/    much too small." - The Young Ones