MUD Server Logic Control?

Steve smorrey at gmail.com
Fri Feb 16 12:11:51 MST 2007


Hey there everyone,
My MUD server is nearly complete.  I can connect up clients and get a
nice MOTD message out.  My handshake features a full MTU discovery
path, and hey they can even chat with one another.  Finally, spatial
and movement data is even being sent and re-broadcast properly.

But I'm at a bit of a crossroads here.
I want to be able to easily modify and extend the server, so a
scripting language would be ideal.

I'm not married to any scripting languages at the moment, and I do
have a distaste for most of them.  I'm really wanting to just roll my
own using something like Lua as a base to build from.

But the problem is I've never built a scripting language before.  And
to be honest I want to avoid the mistakes of others that have come
before.  In my last thread about worst language ever there were some
real eye openers especially that messed up MUD server script language.
 I want to avoid that like the plague if at all possible.

So here's my current plan, I'm hoping someone who's been involved in
language and/or MUD design in the past will be able to point out flaws
in my current design.

At present, there are 3 places where a scripting language would be
especially helpful.

#1 Configuration of server options, (Listen to port 666 etc)
#2 Rules Logic (Player A stabs Player B for 100!)
#3 Server Status Monitoring and Reporting (I'ld like to have a
terminal that I can get to remotely, and use as an interpreted
environment)

For #1 a scripting language is probably overkill but I'ld like to be
able to eventually have #2 and #3 modify the present options on the
server, so for instance if the server gets completely empty, it should
unload the area it handles and do it's garbage collection routines
then go to sleep.

#2 is what scripting languages are made for, easy iteration of code
:), but I worry about the potential slow downs of having any scripting
engine be handed a responsibility that may be called hundreds or
possibly thousands of times per second and addressing thousands or
tens of thousands of objects in the area.  This is my reason for
choosing Lua as my base rather than something more bloated like
python.  There have been tests (albeit a few years ago) that showed
Lua as performing closer to native C than any other language tested at
the time.

So I guess the question then would be, was the problem domain of those
tests close enough to the problem domain of my own tests to justify my
choice?  I've tried googling for the refferences, but all the links
come up dead.  It was called something like "The Great Language
Shootout".

Just for refference my problem domain here is ... Application of D&D
style rulesets to user and environment generated events, between 2 or
more affectors (objects, players etc).  In a nutshell it all comes
down to dice rolls between 2 or more objects to determine final
outcome, choosen from a list of potential outcomes. (Come to think of
it, it's starting to sound more like a job for LISP than Lua).  Again
my goal here is to provide an easy method of customizing, tweaking,
nerfing or whatever the interaction of the rules system to quickly
provide balance.  Doing this in C/C++ would require a recompile at
each code iteration, and since I expect that there will be a whole lot
of code iteration while I seek a balance, I just don't see C as being
appropriate here (too many recompiles etc).  However this job really
isn't complex enough to justify introducing the weight of the Python
VM, in my opinion either :(

#3  The console could very easily be something as simple as the Lua
command interpreter exposed to a specialized client via a TCP
connection.  I just want to be able to go in at anytime and "see what
the server is thinking", then make it think something else if needs
be.  Sorry if thats not very clear, I've seen what I want before but
I'm having a hard time describing it, other than "just a console,
nothin fancy".

So I'm curious to know the thoughts of the programmers here on my
overall design choices before I go through with these last few steps.
I have placed considerable thought into my design, but something here
still "just don't feel right".  And it's been my experience that if
something doesn't feel right, it probably isn't.

Thanks in Advance!

Regards,



More information about the PLUG mailing list