[vworld-tech] Modern MUD server design

[Brian Hook]

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

> This is why, for example, old versions of NCSA Telnet for the
> Macintosh would not connect to any existing Diku, Circle, or Merc
> MUD (to name a few variants) - it waited for a response to it's
> IAC's.

Heh, well, I can imagine that.  Sad that hasn't been fixed in any of 
the servers.

> Just provide a bottleneck command-processing function (er, player
> input), and a standard bottleneck to output, and then you should be
> able to modularize your input/output well enough that it doesn't
> matter what you hook on to it as far as clients.

That's the plan.  Right now the kernel gathers input, strips out 
non-printing characters, then hands the buffer + socket to Lua, which 
appends it to a queue where it can handle actions during the tick() 
phase (I decided to do that just to make it cleaner instead of having 
two separate command processing dispatch sources).

> This is true.  The current version of the GPL specifically does not
> cover the rights of a network user, but only refers to a User,
> defined as ... I'm too lazy to look it up, but the person who
> actually assumes responsibility for executing the code and/or
> making changes to it.

Yeah, I'm not too stressed about it.  I figure in a best case scenario 
I develop The Most Bitching Commercial MUD Codebase EVAR!!11 and I get 
a bunch of licensees, and since they'd get source, screw it, I'm still 
covered.

Then again, looking at PostgreSQL, I may switch now, since it actually 
looks like the docs are better than MySQL's, and I like their emphasis 
on robustness even if it means slower theoretical performance.

Also, the traffic characteristics of a MUD are probably radically 
different from that of a Web page (e.g. in my architecture I'm looking 
at a single connection, not a bunch of temporary connections).

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

Brian