[MUD-Dev] Re: Collecting ideas for a MUD server... (fwd)

[J C Lawrence]

------- Forwarded Message
Newsgroups: rec.games.mud.admin
From: "Daniel A. Koepke" <dkoepke at SPAMGUARD.california.com>
Subject: Re: Collecting ideas for a MUD server...
Date: Tue, 21 Dec 1999 11:44:57 -0800

On Tue, 21 Dec 1999, Wesley W. Terpstra wrote:

> Our plans (at present) are to make a compiler/interpreter for a custom
> OO language and build the actual MUD completely in this language. As I
> understand it, MOO already takes this approach. What I would like to
> gather is a list of features that people consider essential to a MUD
> programming language.

As do LPMUDs, Pike-based MUDs, ColdMud, CoolMud, and a handful of others.  
There's no shortage of Mud drivers, really.  Although new entries are
always welcome.

As to what people consider essential to a MUD programming language, that's
heavily dependent upon what you're intending to express in that language.  
Regardless, the language should:

    * be high level and provide good string and list management;

    * not have pointers;

    * have a consistent, clean syntax;

    * eliminate superfluous syntax constructions, especially those that
      give the coder "artistic freedom" with the code;

    * for OO languages, multiple inheritence is nice;

There are a number of other features the language should have.  My reasons
for the above core requirements:

    * strings and lists are integral to any Mud; simplified handling of
      them over C is important.  A character type is less important, and
      could safely be eliminated given an expansive-enough string and
      list implementation.

    * pointers are not always bad things, but here they are.  Too much
      trouble for what they're worth, and with built-in string and list
      management, there should be no reason for them.

    * try to eliminate keywords/operators that shift in meaning by context
      as this leads to confusing code.  Keep the purpose and priority of
      each operator very clear; avoid reusing operators for different
      purposes.  I.e., using '+' for arithmetic and for concatenation is
      sometimes confusing, and usually bad form.

    * e.g., in a C-based language, eliminate the semi-colon and force
      statements to appear on separate lines.  Be much less flexible than
      C (to demonstrate how flexible C is, try:

          char abc[4] = "abc";
          printf("%c\r\n", 1[abc]);

      and see what you get).  My rationale here is that Muds are much
      more controlled environments underwhich to program; while artistic
      and obfuscated code is a great diversion, there's no reason to
      permit such abominations in a Mud.  Enforce good style (to a point)
      in the language; leave other matters to a Mud's style guide for its
      coders.

    * to make a Dwarf Fighter mobile, I should inherit instances of a
      Dwarf object, a Fighter object, and a mobile object.  These are
      abstract interfaces (i.e., these objects do not appear as instances
      within the game world by-themselves) and can be used to construct
      the attributes of new entities of several types with a minimum of
      code repition.  One of the major benefits being that if I have a
      Shovel which inherits the classes Steel_Spade and Wood_Shaft, and
      I decide to make Pitchfork (which derives from Steel_Fork and
      Wood_Shaft) stop working if its in a fire (i.e., we destroy the
      Wood_Shaft), I implement this new feature in Wood_Shaft and then
      Shovel and Pitchfork share this feature, without both having to
      reproduce the Wood_Shaft code and having completely different
      player actions (provided by the utility of the Spade or Fork).

Of course, better than implementing an entirely new language, etc., etc.,
you might go the course of using an existing extension language.  Scheme
is a nice language (if you've got a Lisp fetish, anyway).  There are many
others.

> I also wanted to know of what MUDs currently implement any of the
> following: multithreading,

Hrm.  I can't think of any off the top of my head.  I'm pretty sure a few
do, of course.

> guis,

That's a client-side issue.  At least, if you mean to say a graphical
interface to playing the game.  There are several things out there that
fit this bill, possibly too numerous and varied to list.  There's a list
of graphical Muds at The Mud Connector.

> exploiting client processors,

Again, that's a client-side issue.  It's relatively trivial to offload
some of the work of the main Mud to the client.  Also, however, it's
relatively pointless with the vast majority of Muds.  I've seen very few
Muds running over 5% of the CPU with good reason.  Which isn't to say
yours won't be one of those few; just insure that you have a purpose in
the exploitation, and aren't just introducing network lag on cheap
computations.

> pgp certificates about players so their characters can move from one
> server to another w/o the two servers ever talking directly.

None (that I know of).  There are Muds that allow passing of players to
other servers.  Uber/Unter, Cool/Cold might be valid research.

A better thing to do than listen to me, here, is to check the Mud-Dev
archives, located at http://www.kanga.nu/.  Follow the appropriate, and
logical links, to the Mailing list archives.

- -dak : Remove my SPAMGUARD to e-mail me.  Yeah, it's silly...

------- End of Forwarded Message



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev