Fume: A Multi-User Virtual Reality Conferencing System


Analysis of current social-oriented muds
----------------------------------------

TinyMUD
-------

System: Entirely command-based.  User modification of the environment
is restricted to modification of the virtual world database, i.e.
building.

Drawbacks: Inflexible.  Not possible to combine methods of database
modification.


TinyMUCK
--------

System: Hardcoded command language and a restricted extension
language.  Users with permission can write code in MUF to perform
tasks.

Drawbacks: MUF is stack-based, has no concept of variables local to
procedures, and is difficult to read and maintain.  MUF has only
primitive data-handling capacity.  Also, there is no convention for
ensuring that all simple database operations will be possible in
both the command language and the programming language, or that
programmers have the same privileges as general users.


TinyMUSH
--------

System: Command language with enough macro capabilities to perform
most tasks.

Drawbacks: There is no particular organization to the macro system.
In many cases the user runs into quoting conflicts.  Data handling is
a joke.  There is no way to abstract procedures so that they act like
primitives.


UnterMud
--------

System: Hardcoded command system with macroing capabilities, and an
unrestricted programming language.

Drawbacks: Data handling allows lists but not arrays; there is again
no good abstraction system.  There are no unrestricted loops.


MOO and COOL
------------

System: Integrated language; MUD is implemented in language.

Drawbacks: Overhead, sometimes abstraction problems.  Again, no
unrestricted loops.



Restrictions
------------

Fume should satisfy the following restrictions:

* Code should be readable and easily maintained
* There should be a concept of local variables
* Restrictions on time should not get in the way of implementing
  algorithms.
* Users should not have to resort to string searches on property lists
  to handle compound data types.
* Compound data types should be database objects, however, to
  facilitate sharing and to prevent use of dynamic allocation.  (All
  arrays are global and static.)

In general, conserve space, and dael with speed in a sophisticated
manner rather than severly restricting the system.

Wish list:

Catch/throw


Tentative conclusions
---------------------

Interpreter types are used on the stack and in property lists.  They
should be numbers, strings, and dbrefs.

Database types should include the standard types (rooms, players,
exits, programs) as well as arrays and perhaps tables.

Language needs a preprocessor.