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

[Rahul Sinha]

On Tue, 21 Dec 1999, J C Lawrence wrote:

> 
> Wesley: I crossed your post to MUD-Dev for further comment.
> 
> ------- Forwarded Message
> 
> From: "Wesley W. Terpstra" <terpstra at iota.dhs.org>
> Newsgroups: rec.games.mud.admin
> Subject: Collecting ideas for a MUD server...
> Date: Tue, 21 Dec 1999 11:35:13 +0000
> 
> Some friends and I were thinking about writing a new MUD server from
> scratch and I thought it would be wise to collect information from
> people who have been running&coding them. :-)
> 
> 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.

is this more advantageous than coding the mud in C++ and making it
scriptable via this language, that way you can have whatever language
features you need to write the mud, and still avoid making the scripting
langauge overcomplicated....

> 
> I also wanted to know of what MUDs currently implement any of the
> following: multithreading
A Good Thing...

>guis

making your mud room-less?
so long as you keep your mud interface agnostic its ok... this will
distract you from the rest of the mud, as a decent gui interface takes
work (if you are doign more than simply applying menus and mapping as gui
stiff...)

>exploiting client processors, 
implies a client-side program (as opposed to useing telent or ssh to login
to server...)

I personally don't liek the idea, esp as cross platform is an issue unless
you want to go with Java <blech>

I personally am splitting up the traditional mud structure into a
inetd-based concurrent server that is jsut the client program (ie here
lies presentation, mapping stuff, etc), that connects via loopback to a
"event server" that handles movement, etc, all physically manifested
stuff, both using MySql for data storage, and IC AI stuff is implemented
by virtual clients connecting to the event server from mob programs.

all commands are implemented as shared libraries, so that they can be
dlopen()ed during runtime (so as to not have to take down server)

more details to come as more code exists ;-)

>pgp
umm if you are talking about encrypting the text stream, just pawn off ssh
now that there is an opensource version of it... pgp is more for
non-streaming data authenticaiton and encryption

> certificates about players so their characters can move from one server
> to another w/o the two servers ever talking directly.
servers talking is much better than trusting the client.  Clients can be
reverse-engineered...

> 
> Thanks alot.
> 
> - ---
> E-mail: terpstra at interchange.ubc.ca        Host: iota.dhs.org
> PGP key: hkp://wwwkeys.us.pgp.net/terpstra@interchange.ubc.ca
>          http://www.iota.dhs.org/pgp-keys/terpstra.pgp
> 
> ------- End of Forwarded Message
> 
> 
> 
> _______________________________________________
> MUD-Dev maillist  -  MUD-Dev at kanga.nu
> http://www.kanga.nu/lists/listinfo/mud-dev
> 

	Rahul Sinha
Computer Science/ Government,
University Of Maryland College Park
AIM: qui dire	ICQ: 9738191	(301)935-5542





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