[MUD-Dev] Collecting ideas for a MUD server... (fwd)
rsinha at glue.umd.edu
Wed Dec 22 05:02:59 New Zealand Daylight Time 1999
weee buzzword bingo
On Tue, 21 Dec 1999, Justin Rogers wrote:
> [JC Lawrence]
> > 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. :-)
> Not a bad idea. Press the limits though and make it expandable. Use plugins,
> new technologies (ActiveX), different network protocols, etc... If your
most muds run on Unix, with good reason, stay FAR away from activeX,
unless you think your mud shoudl run on a server with the GUI in
regarding new protocols... why?? no need exists... if you want clear text
clearly no change needed, if you want encryption, go steal some OpenSSH
code (its BSDed, so you can use whatever license you like for your product
even if you use their code)
> making a new one then go for broke.
... change whats broken...
> > 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.
> Sounds nice. I programmed an ActiveX scripting language that I then connect
> to through a plugin. It handles all basic arithematic and the such. The actual
> RexxScript, DigiScript (mine), as DLLs (must support custom interfaces), as
> ActiveX controls (also must support custom interfaces), and as TCP/IP servers
> that return formatted control streams.
once again, keep in mind that a) your players are not all running GUIs
(unless that is a design requirement) and b) if you are going to make your
mud graphical, speed issues exist with the embedded-into-webpage idea...
hence why games like SPQR died out...
Justin's plan locks you into a) windows b) guis and c) is unnecissary if
you want to write a windows gui-client mud
> [JC Lawrence]
> > I also wanted to know of what MUDs currently implement any of the
> > following: multithreading, guis, exploiting client processors, pgp
> > certificates about players so their characters can move from one server
> > to another w/o the two servers ever talking directly.
> I don't know about existing muds that support too many of those things. I've
> coded a plugin driver that accepts different types of plugins that interact
> and create a game. Several of these plugins support multithreaded users.
??? multithreaded USERS?
> A couple of export plugins use DirectPlay over the Internet and DirectX
> streams with personally coded clients to stream 3D arenas (very small).
cross-platform and speed issues here... if you must use DirectPlay don't
stream it across the Internet, have the user dl a client... (once again,
if you are not going into a GUI-only setup, you REALLY dont want this
> These clients therefore use quite a bit of the clients processors. And one
> plugin if used properly and installed on all clients can create a MUD without
> any server at all. Just the users.
ummm a peer-to-peer setup is not safe for any centralized game... Justin,
have you actually implemented this? If so, you are begging for some player
to remember that he can hexedit his character...
and if you are streaming DirectPLay, how is this peer-to-peer? (iow you
NEED a client-server setup)
> - Justin Rogers, CEO DigiTec Web Consultants
Computer Science/ Government,
University Of Maryland College Park
AIM: qui dire ICQ: 9738191 (301)935-5542
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev