[MUD-Dev2] Text based MUD's - State of the art (if any)

[Zach Collins Siege]

On Mon, Apr 20, 2009 at 5:12 AM,  <matthew.owen at barclays.com> wrote:

> I'd say, if you've got the time, then go for it. I found writing my own MUD
> codebase very enjoyable. It also enabled me to tackle some code scenarios I'd
> never hit before. It's very different beast writing a state engine for
> multiple players compared to a GUI based single user application. The end
> result was that I'd created something I was proud of, and something that
> others (for a short while) enjoyed playing. I also improved my coding skills
> no end because even a basic MUD engine requires 1000s of lines of code - it's
> not a trivial 'Sunday Afternoon Project'.

Thousands for some; it all depends on what you want in your game.
(reference http://www.andreasen.org/16k.shtml - 16K MUD competition
from year 2000)

I expect (writing in Python and my own internal MU* language) that the
MUD I had planned out a few years ago would have had only a few
hundred lines in the primary system which instantiates and oversees
all the engines (network, database, game, monitor) and non-game
subsystems, and then perhaps a few hundred each for the three
different game engines I was going to provide for it
(combat/skill-use-focused game, Chatroom/talker with minimalistic
channels/rooms and available network bots for linking to IRC or
another game, socially-focused game) and the internal scripting
engine.

Each of these were things I hadn't really done before, which even if I
didn't write much code certainly helped improve my design skills: How
do I make a process queue that allows for delayed commands and runs as
quickly as possible? What features are really necessary for telling an
object how to behave? What features can be abstracted from each of
these very different systems, and should I abstract them to
sytem-level, engine-level, in-game, or externally-loaded libraries?
How do I detect when subsystems have stopped functioning, or new
libraries are available, and can I restart/reload them without having
to restart the whole system? What about backup/restore compatibility
and database transitions when an update changes the object model or
database engine?

By the way, if folks want to see my answers to the questions above,
I'd be happy to split off a Design thread to talk about them; though
I'm sure a few of them have been rather elegantly answered before. :)

-- 
Zach Collins (Siege)
"If code can be speech, then software can be art."