[vworld-tech] Modern MUD server design

[Patrick Dughi]

> -----Original Message-----
> From: vworld-tech-bounces at cubik.org
[mailto:vworld-tech-bounces at cubik.org] On
> Behalf Of Brian Hook
> Sent: Thursday, January 22, 2004 2:56 PM
> To: vworld-tech
> Subject: RE: [vworld-tech] Modern MUD server design
> 
> > You don't have to stress yourself out so much.  A sampling of MUD
> > servers source code that's available will quickly show you that
> > apparently no MUD developer has ever implemented full telnet spec
> > compatibility.
> 
> I'm just trying to figure out the minimum expectation.  For example,
> Cygwin telnet (which I'm assuming is identical to Linux's telnet)
> broadcasts ^H, which I had assumed any decent, unshitty line-oriented
> implementation would have handled.
> 
> > Most usually provide an echo on/off packet, but do
> 
> I assume the default is to request local-echo on?

	Actually, I don't believe any document lists any default values;
they're all meant to be negoiated.  The unofficial-official setup for
the last 10 years however, has been to try to manage char mode,
including echo off.  The previous 10 years before that were attempting
either line mode, or a variant known as line-mode kludge, with echo on.

	Most existing MUDs today hearken back to a day ..well.. more
than 10 years ago.  They almost uniformly assume line-mode kludge, with
echo on by default where applicable.  

	Mileage may vary.

	Other items such as the value of a delete character are
increasingly tricky with linemode.   Most MUDs assume, and leave it at
that.  I don't know the correct way to handle this offhandedly in line
mode.  With character mode, it's fairly simple to handle; you can simply
say 'delete is \008 or \127' (backspace and delete, respectively, unless
I messed that up) and it will be your server managing each item, and
you'll be echoing it back to the user.

	It's also necessary if you want to - for example - do something
with those arrow keys, like shell-style command history, or heaven
forbid, moving.  Still, a MUD with command/name completion would be
quite neat.
 
> > What I'm pointing out is that if you want to provide continually
> > changing _dynamic_ content, you're going to want to provide a
> > scripting language that is as easy as possible to use for the
> > potentially non-technical guys out there that will be doing your
> > area design, or creating new monsters, or what have you.
> 
> Actually, I would argue that what is far more important are tools, not
> the scripting language.  If you look at a typical MMOG or even single
> player RPG, while there may be a lot of scripting, it's often
> black-boxed and the bulk of the content consists of data entry.
> 
> Speeding up and optimizing data entry is what I'm mainly focusing on,
> ideally with a Web and/or builder client where you can trivially do
> stuff like "Make me a sword like this one", enter some fields, then
> hit "Publish" and you're done and it's in the game.
> 
> > fastest way to get that done is to write a _good_ building tool,
> > and release it on trusted level creators.
> 
> Yes.

	You corrected me before I corrected myself, it appears.  Good
tools are the most important for high productivity.  The capabilities a
scripting system are second compared to the user's ability to access
them.

	PjD