[vworld-tech] Modern MUD server design

[Patrick Dughi]

> >> 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.
> >>
> >
> > Why is that?  What advantages are there to writing the game logic
> > in a scripting language versus writing it in the same language as
> > the kernel.

... All the things that Brian (Hook) said (not duplicated here) plus all
the things that the other Brian (Crowder) said.. phew, plus my own,
based on productivity:

	Providing a full featured scripting language that runs in a well
defined sandbox can let the programmers write code and not concentrate
on content.  Both require the same level of concentration and support,
but each time your programmers have to sit down and write in a check to
determine a player's status and play a specific hardcoded media file, it
takes away from time they should be spending making sure the media file
actually plays correctly, or to stop the game from crashing, etc.

	Aside from that, given a standard gaming engine, scripts are
immediately portable.  Look at the proliferation of ZMUD scripts, LPMUDs
in general, DGScripts in the CircleMUD world, or MUSH scripts for..
well. same base mushes.  Scripts port well because they're interpreted
by the game engine and so don't care what system they're running on.

	There's also the added advantage that by not tightly coupling
your code with your script, items can (potentially) be interpreted in
place, instead of requiring recompilation.  Graphic effect designers are
extremely familiar with this; after all, who wants to have to recompile
just because the trailing edge of a gauss rifle blast wasn't exactly the
right shade of blue-white, or the streak lasted just a bit too long.  Of
course, this is just as valid in the MUD world too; you don't want to
have to recompile because your merchant was delayed by a PC, and so
attempted to lock the door and leave for the night in the wrong room...

	Last, and again, focusing on a productivity bent, lets look at
having more than one person working on your system at a time.  It
doesn't matter how simple or how complex an item is, every line of 'real
code' has the ability to crash the system or screw up someone else's
code.  This doesn't come up as an issue if you're the sole developer,
but if you have a team (especially if it's a loose knit hobby-level
team), it's hard enough just managing source control, much less ensuring
non-crash-bugs don't creep in.

	And you will get crash bugs that you didn't write, inevitably. 

	However, in conjuction with the tight sandbox previously
mentioned, you can have scads of level developers writing masses of
scripts and never once worrying that one person will be introducing a
show stopper, or becoming a gating item for the rest.

	Maybe it's just me, but I see productivity being the biggest
issue in writing my own hobby game, but I'm sure it's even more
important for commercial games with ever shrinking deadlines and budgets
and pre-announced release dates..

	PjD