[vworld-tech] Modern MUD server design

[Patrick Dughi]

> > If it's a text mud and you want lots of users, I vote for pure
> > telnet, or else write a client that's easily accessible from the
> > web.  (ie. in Java -- or maybe C#?)
> 
> I'm going to support telnet + telnet w/ suboption negotiation for
> proprietary featuresd + possibly a custom downloadable client with a
> featureset similar to that of Simutronics' StormFront, zMud, et. al.
> 
> One of my goals is to make the game approachable by non-MUDders, so
> giving up pure telnet compatibility may not be that big a deal.  A
> Java client might be nice though.

	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.  Most usually provide an echo on/off packet, but do not
look for responses.  In fact, most simply discard any unprintable
characters that come down the line.

	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.

	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.

	Besides, most custom Java MUD clients simply take an existing
Telnet applet, and add a few buttons around the edges.  Those buttons do
nothing more than insert a pre assembled text string into the 'send'
buffer - like macros.  So it's pretty simple to provide for web users
without much change.
 
> Lua has a pretty solid license as well (MIT I think).

	As of version 5.0, it is under the MIT license, and
incidentally, that means it's GPL compatible.  Previous to that, it was
under it's own zlib-like license, but still GPL compatible.

> Ironically, I'm under the impression that if you write a server but
> don't distribute it, you can use GPL and not have to release your
> source code (of course, I'm sure someone here will correct me =) ).
> Then again, I don't use GPL software, so anyway...

	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.
 
	There has been sort of a minor revolution, though I can't point
to the roots of it; there is much emphasis by NONE of the major players
to make the next version of the GPL the 'Affero' license, found here;
http://www.affero.org/oagpl.html.  I've gone into some depth with the ..
poor wording, and lack of definition with this license which is, in a
nutshell, GPL with the same rights for users of network software as
those who execute the software.  

	In other words, if a MUD were put under the Affero license, any
player can require that you provide them the current existing code, and
of course any additional software, code, or mechanisms required to make
it 'go'.  It doesn't specifically cover data files, scripts, or other
items, so those are up in the air.

	Depending on who answers your 'question about the GPL' at
.gnu.org, you may get an FSF based reply that says "oh, those things
will be fixed in the Affero License, just use that."

	Sadly, unacceptable to most server-based games, for many various
reasons.

> Actually, I think the most interesting decision is whether to write
> everything in a higher level language and call into C or vice versa.
> A lot of people have recommended I just bite the bullet and write the
> whole damn thing in Python and call into C only for performance
> intensive stuff.

	There's something to think of here - most games today are
content driven.  Sure, back in the day, the programmer was responsible
for providing everything from the game engine, to the level layout, to
the 'art' for the in game creatures.  That was great when games fit on
floppy disks.   Today though, games have somewhere between 5-20 man
years of art alone packed into them, and the programmer is almost never
the person doing level design.  There are people who make a decent
living doing little more than level design (though usually that's folded
into a CSR position as well.. creative design if they're lucky (aka,
story, plot, mechanisms, etc)).

	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.  

	This is even more important for the hobbyist; just writing the
code takes so much time that there is almost none to spare for the vast
creative process required to populate your virtual worlds.  The fastest
way to get that done is to write a _good_ building tool, and release it
on trusted level creators.

	Look at games like Morrowind, which allow a graphic artist to
create not only a whole new race (with flapping wings and full 3-D
animation controlled in much part by scripting), but also new skills and
abilities.  I'm speaking specifically of Mac Hall's Mog mod, which
introduces such elements into the Morrowind world as a little cat/dog
person with a dealy-bob on his head, wings, the sword from FF7, and the
ability to steal a person's pants without their knowledge.  You can view
a somewhat humorous retelling of this on the Mac Hall website;
www.machall.com, look for 'MOD*MOG' down on the page.  

	Then again, Morrowind is pretty impressive in its script
capabilities all-in-all.

	PjD