[vworld-tech] Modern MUD server design

[Brian Hook]

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

The script system will be able to call into the kernel for both 
"system traps" (e.g. send data to this socket) and for accelerated 
versions of routines that are otherwise too slow.

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

I'd like this flexibility, but there are a lot of problems associated 
with changing things on the fly with regards to handling live 
entities.  I'm not too concerned with taking down servers to push new 
behaviour (I definitely won't need to take down the server to get new 
data, but new behaviour will require it right now), given that many 
popular MMOGs do just that (EQ being the obvious one).

> 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

Actually, it's on another computer altogether.  The network is defined 
like:

MySQL <----> World <-||-> PLAYERS/INTERNET

Where || is the firewall.  The MySQL database is only directly 
accessible by the world server, which performs queries for specific 
data, and then uses a local write-through cache to prevent queries 
from bogging things down.

The high-level looks kind of like:

script 'GetItemInfo' -> kernel "GetItemInfo(item)" -> cache -> DB

Obviously if the DB is updated asynchronously, e.g. external tools, 
then you have to do some kind of invalidation on the cache, but the 
nice thing is that new data is propagated immediately.

> Portability gets hairier when you introduce threads, though, so I
> like IPC/multi-process better, usually.

The portability isn't a big issue, but in general I'm not a big fan of 
gratuitous threading.  It tends to introduce more problems than it 
solves.

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

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

Probably, and yes.

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

Currently input is handled immediately, so 
actions-that-result-from-input get priority over 
actions-that-result-from-a-timer, which makes sense (since the action 
showed up before the timer).

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

Well, obviously more functionality than just "script_tick" is in 
order, but babysteps, man, babysteps =)

I've been working on this for about 12 hours and have a telnet server, 
scripting integration and a basic event loop working, so I'm A.) doing 
okay but B.) still not very far long.

> Why not JavaScript?  

Suhloooowwwwww....not Ruby-slow, but definitely slower than Lua.

> Ruby. Better still, it's a veteran of the Mozilla campaign, and so
> well-tested and proven stable.  Great license, too.

Lua has a pretty solid license as well (MIT I think).

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

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

Yes, and I think that MySQL 4.x has transactions (it has something it 
calls transactions with roll-back, so I'm pretty sure it does).  I'm 
also planning on making a suite of pretty kick ass tools that will 
make entering new mobs, items, rooms, etc. a piece of cake.

> Don't hesitate to go hybrid with data that doesn't need to be as
> dynamic as what a real database offers.

I'm actually using a hybrid approach.  All dynamic/live objects live 
in the game, and are serialized only when absolutely necessary.  
Static data is grabbed from the DB only when necessary.

For example, a lua script may reference a particular sword and needs 
its stats:

get_item_stats( item )

which then ends up calling into the kernel:

void get_item_stats( item )
{
   if ( !cache[ item ] )
   {
     cache[ item ] = DB_QueryItemSTats( item );
   }
   return cache[ item ].stats;
}

(It's actually a lot grosser than that, but that's not particularly 
germane here)

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

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.

Brian