[MUD-Dev] Introduction

Miroslav Silovic silovic at srce.hr
Mon May 12 11:29:58 New Zealand Standard Time 1997

> :A *small* codebase (ideally also under 300k) that's well documented
> :and cleanly coded such that it's easy to extend if necessary.
> That might be a problem. Mine is currently:
> MUD.index		   49524 ----rwed Friday    23:15:35
> MUD.data		  591194 ----rwed Friday    23:15:35
> When you make your server generic, and put all the actual scenario rules,
> etc. in to the database, that can push up the size of the database a lot.
> You can aim for a small one, and it might even start that way, but I bet
> it will grow, and grow, and grow...

Cold has the same problem. Codebase is 1.3 megs (plus builtin docs), and
pretty much all of it is used to drive hypertextual VR and give easy
access to the building and coding.

> Might I suggest that you make your language strongly-typed? Many people
> don't like that (not me!), but it can make it run a lot faster if you
> don't have to do very many run-time checks or conversions. Similarly,

This is an expensive tradeoff, and one you want to think CAREFULLY about.
You can go for strongly-typed (i.e. all /variables/ are declared in advance,
and dynamically-typed (i.e. data keeps type-tags, and types are checked
in runtime). If you do strongly-typed language, you'll be able to compile
it to C without too much pain, and gain a lot of speed. Unfortunately, the
payoff is in the ease of programming. MUD tend to use mixed datastructures
a lot, and when you're able to just say 'this is a list' without worrying
about the types of the elements inside it (as dynamically-typed languages
allow), you can spew working code at blinding speed, and you'll also make
your hired coders much happier.

For that matter, I'm still pondering writing a MUD in LISP or Scheme. There
are *extremely* good compilers out there, some of which produce
numbercrunching code that is up to par with C. You can declare the
variables (to help the compiler) but you don't have to. Macros are powerful
enough that making it parse and run C-like syntax is a two-hours job,
even if you don't use all the yacc-clones that exist for Common LISP and

Once you start using it, you gain access to 20 years of AI software
developed specifically for LISP (for instance, rule-based expert systems,
natural language parsers, graph-analisys tools, to name a few - all have
direct applications in MUD world).

> force people to pre-declare variables, so that you can access them via
> something other than their name at run-time (e.g. an offset from a
> current scope pointer, allocated on entry to the scope).

Uhhh, why do you need that? It looks like terribly unsafe programming to me.
Remember, you'll have a lot of people coding on your MUD (at least if you
want fast development). It seems like a good idea to prevent their code
for having side-effects that are impossible to track.


More information about the MUD-Dev mailing list