[vworld-tech] Modern MUD server design

[Brian Crowder]

Brian Hook wrote:
> I've been dorking around with an experimental MUD server design, 
> nothing genius, just trying different kinds of technology, and was 
> curious what others had to say on it.
> 
> NOTE: I have never seen Diku or LPC code bases, so there is a good 
> chance that I'm doing things A.) stupidly or B.) reinventing the 
> wheel, but that's fine, since I'm doing this for educational purposes.
> 
> The server is divided into three main components:
> 
> * kernel (written in a standard compiled language)
> * game logic (written in an embeddeded scripting language)
> * database
> 

In my opinion, a pretty solid approach.  Of the architectures I've seen 
for both professional and "hobby" multi-user games, the better 
architectures have usually been those that gravitate more toward very 
high-level languages (or structured data) for defining game content. 
Likely, you'll find situations where you'll need machine-compiled 
modules for your scripting language, enabling you to accelerate 
computationally expensive operations like pathfinding or AI (depending 
on how sophisticated your AI is).  If this is intended as a "platform" 
for a MUD, you'll want to define this "module" architecture well. 
Another advantage to interpreted languages is the ability to replace 
chunks of the game on-the-fly, but you'll have to think ahead starting 
now, if you really want to take full advantage of that flexibility. 
Depends how much uptime/availability matters to you.

> The kernel is basically the glue, and has no game logic in it 
> whatsoever.  All logic is embedded in the scripting language 
> (currently Lua), which in turn communicates indirectly to the database 
> via the kernel.
> 

You may later find that you want the DB stuff even further away from 
your game, perhaps in another process (or your kernel has a pool of DB 
threads (maybe general I/O threads?), whichever).  Portability gets 
hairier when you introduce threads, though, so I like IPC/multi-process 
better, usually.

> MySQL DB <=> kernel <=> game scripts
> 
> The kernel manages MySQL communication and TCP socket connections.  
> I'm currently using telnet as my protocol, however I'm thinking about 
> either embellishing it with suboption negotiation for richer data 
> and/or encryption or possibly ditching it altogether and requiring the 
> use of a custom client.
> 
> What are people currently using for secure communications to MUD 
> servers?  I'm thinking of either layering my own protocol on telnet 
> using (sub)option negotiation and/or requiring a custom client and/or 
> using something else like SSL/stunnel.  Key issue being that telnet 
> isn't particularly secure.
> 

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 haven't yet seen a really nice terminal 
"control" for either of these languages, but perhaps I haven't looked 
hard enough.  Do you want to do neat things like have a visual-mode 
"bar" such as what tinyfugue offers?  Certainly, by defining your own 
client-server protocol, you get a lot more freedom even than that.  But 
you make your job harder and potentially shrink your user-base.  Do you 
want to charge people for this game (or for users of your platform to be 
able to charge users for THEIR games?)?  Do you want to be text-only?

> This is written portably and runs on Windows, OS X and Linux (and 
> presumably FreeBSD and other variants as well).
> 
> The main loop is pretty generic.  The kernel gathers up all incoming 
> socket data, strips off IAC data and adjusts state accordingly, 
> buffers until newline (for sucky clients that don't do linemode 
> operation), and for any completed lines dispatches them to the script 
> engine, e.g.:
> 
> script_do_input( buf, socket_received_from );
> 
> When all input processing is done, then the world gets a 'tick' to 
> advance, which is handled as a message to the script subsystem:
> 

Do you actually do "stuff" at this point, or does the input all end up 
getting queued as pending events that you handle in the "tick()" 
routine, or what?

> script_tick();
> 

I'd be interested to know a little bit more about what happens here, 
since this is really the meat of the thing.  If what you're hoping to 
come out of this excercise with is something flexible and usable as a 
MUD development platform, you may want to offer some more mid-level 
functionality at this point (even if it's in Lua, and not the kernel).

> And it does all its gnarly internal updates for mobs, rooms, etc. that 
> it needs to do.
> 
> Some of the rationales:
> 
> - Lua: fast, will have an incremental garbage collector by the time 
> I'm done, easy to embed
> 
> - Why not Ruby?  Heavyweight and SLOW.
> 
> - Why not Python?  No good reason, just bigger than Lua and not as 
> fast.
> 

Why not JavaScript?  Spidermonkey 
(http://www.mozilla.org/js/spidermonkey/) performs well, and lots more 
people in the world know JavaScript than know Lua, Python or Ruby. 
Better still, it's a veteran of the Mozilla campaign, and so well-tested 
and proven stable.  Great license, too.

> - Why not 100% in Lua/Ruby/Perl/Python and just call out to C?  
> Because I'm a wuss and didn't feel like committing that heavily to a 
> language at this point =)
> 
> - Why not postgreSQL?  Because MySQL is better documented and more 
> ubiquitous, however I can easily change this later.
> 

You'll want transactions (I think there's a MySQL extension for this) as 
you mention below, and you'll want to encapsulate them in such a way 
that whoever ends up developing on your platform doesn't have to worry 
much about integrity issues.

> - Why a database instead of flat-file/in-memory?  Transaction 
> oriented, fast access, much better persistency, SQL is powerful as 
> hell, access to third party tools, remote modifications.
> 

This is the rational choice, generally, but one of my greatest 
frustrations in life is watching a production database server die, 
bringing down an otherwise stable service.  It doesn't happen often, but 
when it does there's not much you can do about it.  Don't hesitate to go 
hybrid with data that doesn't need to be as dynamic as what a real 
database offers.

> - Why C?  Actually, I'm suing .cpp files, however I really don't care 
> for C++ as a language (something I really don't want to get into an 
> argument about...again), but there are some elements of C++ that I 
> like that C89 doesn't support (specifically, declare-anywhere).
> 
If it's a platform such as I'm envisoning, the choice of language for 
implementation of the kernel is much less interesting than the scripting 
language you choose.

> Any comments/criticisms are welcome and appreciated.
> 

I'm sure most of what I've mentioned has already occured to you, but 
it's perhaps worth mentioning anyway.

> Brian
> 

-- Brian