[vworld-tech] Modern MUD server design

[Brian Hook]

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

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.

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.

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:

script_tick();

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

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

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

Any comments/criticisms are welcome and appreciated.

Brian