[MUD-Dev] Re: PDMud thread summary

[Darrin Hyrup]

At 01:35 AM 10/22/98 -0700, Jon Leonard wrote:
>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.

Nice job! This thread could use it. ;)

>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

Some of the more game-oriented modules may initially be softcoded in the VM
for ease of testing and modification.  However, it would be nice to be able
to (re-)write them in native code and turn them into a plugin for speed.
Ideally, it would be nice to be able to turn any/all softcode into native
code by compiling once testing is done (if desired/needed.)

>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.

My personal view on security is to allow it to be defined via plug-in or in
the VM.  That way MUDs that allow player access to the programming shell
can have relaxed security and those who don't can have increased, as they
choose.

I also believe that an O-O approach to the design from the inset would be
the best... in both the implementation of the server, as well as in the
design of the internal language.  Ideally, the internal language should
support inheritance (at least single, although multiple would be nice in
some situations.)

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

As well recieved as Java has been in the developer community, I'm not sure
there are enough people here with the degree of Java skill to implement the
driver in it.  Not to mention, it wouldn't exactly be rocket fast.  For
sake of speed, familiarity, and in order to remain an instructional aid for
other new mud developers, I suggest we probably should stick to C or C++.

I suggest that if we do a textual client for this project (which seems
reasonable, just for completion sake if nothing else), that we look at
coding that in Java.  (I would look at that as a good justification to
learn the language.)

>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.

Sounds good to me. :)

>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. 

Great!

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

I agree... at least we would have to have local mirrors for development
purposes if nothing else.

Best,

Darrin