[MUD-Dev] PDMud thread summary

[Jon Leonard]

There's been enough discussion about collaboration on a MUD a that it's
starting to get tricky to follow, so I thought I'd try to provide a summary.

I'm excluding from this summary discussion of what an in-game language
(and it's virtual machine) should look like.  There's enough on that topic
that it deserves its own summary, and I'm too tired to do that tonight.

If I've missed something important or unduly colored things with my
viewpoint, I'm counting on people to speak up and fill things in.
If you want to know exactly who said what, consult the archives.
(Otherwise this would be lots longer.)

The summary:

It looks like there are enough people on the MUD-Dev list interested in
collaborating on writing a server that it'll happen.  It needs to be
be flexible enough in design and flexible enough in license that it
can be reused by anyone in lots of settings, including commercial ones.
There doesn't seem to be anything out there that fills this niche yet,
though the Cold Project at least comes close.


License:

There have been several suggestions as to what license to use, including:

GNU Public Licence (Problematic for commercial use?)
BSD
Perl's Artistic License
X Consortium License
Public domain (disclaiming all liability -- there may be legal issues)
Beerware ;)
Free to anyone who makes a contribution to the code.

It's possible that different pieces might wind up under different licenses.


Goals:

Not everyone has the same interests, though there should be enough overlap
to make a viable project.  Some things that people want:

An advanced server.
A server suitable for experimentation
Something suitable for use in running a commercial service.
Code that's easy to learn from.
A bunch of mix and match pieces.
Rapid development environment.
A distributed server (platform independence, too)
A portable server (Is strict posix portability what we want?)
A scalable server (It should run on future hardware too.)
A sophisticated in-game language.
An efficient server (It should support hundreds of players on small machines.)

Some people might only be interested in a plug-in language.  I don't think
this is a problem, because a simple MUD to plug it into shouldn't be very
hard to write.


Structure:

It should be a collection of mix and match modules, reconfigurable
even at runtime via dynamic linking.  Many of the pieces should
behave like pieces of an OS.

This allows for lots of flexibility for individual MUDs, understandable
pieces, and answering the question "Do we hardcode or softcode this?"
with "Both".

Possible modules so far:

Bootstrap (module handler)  
Database storage/persistence (relational or Object Oriented)
Telnet server
Client/server messaging (for sophisticated clients than telnet)
Client graphics control
Magic system
Movement
Rooms & objects manager
Coordinate based location
Spatial data structures
on-line building
Event manager
Command Parser
Command Executor

... and a whole bunch of modules related to in-game language(s), including
building modules in the in-game language and compiling to machine code:

Byte-code VM (Use the Java VM?)
 and compiler
 and debugger
 and so on...
Various interpreters
Existing embeddable languages: Python, Perl, Tcl, etc.

The interfaces between modules looks like it should contain at least:
Functions, callbacks, unique IDs, and possibly events.  We definitely
need a standard calling convention.

It's not clear how to fit security into this.  There's also some disagreement
as to what extent the design should be object oriented.


Implementation language:

I've seen four suggestions:
C
C++
Java
A mixture of languages, which probably means using C calling conventions.


Project home(s), project maintainer(s):

I'm volunteering to be project maintainer, keeping track of source code,
releases and so forth.  If someone else wants to, thats fine too.

I'm also volunteering to host the project on one of my computer,
Frost.slimy.com.  (also [www.]{mud,pdmud,openmud}.slimy,com.)  It's a
600 MHz Alpha running Linux, with a 24x7 160 Kbit network connection.
It's available for web hosting, source hosting, running servers, etc.
I paid for this out of my own pocket, so there aren't any strings attached. 

It might be a good idea to have modules maintained by different people,
with different machines as home.  Everything should probably get mirrored.


Jon Leonard